How do I remove this deprecation warning I'm getting with scala 2.8 concerning case classes?

RingRecipe looks fine but shouldn't be subclassing anything that's also a case class.It looks as though GearRecipe *is*, which is causing the warning.

On 29 April 2010 21:52, Ken Egervari <ken [dot] egervari [at] gmail [dot] com> wrote:

Hi,

I'm getting a compiler warning that looks like this:

warning: case class `class RingRecipe' has case class ancestor `class GearRecipe'.  This has been deprecated for unduly complicating both usage and implementation.  You should instead use extractors for pattern matching on non-leaf nodes.

I get this with the following code (and much like it):

case class RingRecipe(
    override val name: String,
    override val requiredLevel: Int
) extends GearRecipe(name, requiredLevel) {
    type ItemType = RingRecipe
    def likeKey = new RingRecipe(name, requiredLevel)

    type CraftableItemType = Ring
    protected def newInstance(id: Long) = new Ring(id, name, requiredLevel)
}

I must admit, I'm not doing much pattern matching on these classes. I basically generate a case class because it saves time ;)

Solution?

Ken

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Yeah, unfortunately, they both have to be case classes ;)

I wonder if I could just remove these recipe subclasses altogether. I think that's what I have to do :/

Ken


On Thu, Apr 29, 2010 at 5:26 PM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:

RingRecipe looks fine but shouldn't be subclassing anything that's also a case class.It looks as though GearRecipe *is*, which is causing the warning.

On 29 April 2010 21:52, Ken Egervari <ken [dot] egervari [at] gmail [dot] com> wrote:

Hi,

I'm getting a compiler warning that looks like this:

warning: case class `class RingRecipe' has case class ancestor `class GearRecipe'.  This has been deprecated for unduly complicating both usage and implementation.  You should instead use extractors for pattern matching on non-leaf nodes.

I get this with the following code (and much like it):

case class RingRecipe(
    override val name: String,
    override val requiredLevel: Int
) extends GearRecipe(name, requiredLevel) {
    type ItemType = RingRecipe
    def likeKey = new RingRecipe(name, requiredLevel)

    type CraftableItemType = Ring
    protected def newInstance(id: Long) = new Ring(id, name, requiredLevel)
}

I must admit, I'm not doing much pattern matching on these classes. I basically generate a case class because it saves time ;)

Solution?

Ken

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

You can get 100% of case class functionality without actually being a case class.
Depending on the exact case class features you need, you'll want to do one or more of:- mark the constructor params as vals - define equals and hashcode- define Apply in the companion object so it takes the params and returns a new instance of GearRecipe, this gives you the construct-without-new-keyword syntax- define Unapply on the companion object, making it an extractor, for use in pattern matching


Of course, once the companion object is both a factory an extractor you can feel free to change the constructor signature as needed to make your life easier - it's not as though you're likely to use it directly any more.  

On 29 April 2010 22:45, Ken Egervari <ken [dot] egervari [at] gmail [dot] com> wrote:

Yeah, unfortunately, they both have to be case classes ;)

I wonder if I could just remove these recipe subclasses altogether. I think that's what I have to do :/

Ken


On Thu, Apr 29, 2010 at 5:26 PM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:

RingRecipe looks fine but shouldn't be subclassing anything that's also a case class.It looks as though GearRecipe *is*, which is causing the warning.

On 29 April 2010 21:52, Ken Egervari <ken [dot] egervari [at] gmail [dot] com> wrote:

Hi,

I'm getting a compiler warning that looks like this:

warning: case class `class RingRecipe' has case class ancestor `class GearRecipe'.  This has been deprecated for unduly complicating both usage and implementation.  You should instead use extractors for pattern matching on non-leaf nodes.

I get this with the following code (and much like it):

case class RingRecipe(
    override val name: String,
    override val requiredLevel: Int
) extends GearRecipe(name, requiredLevel) {
    type ItemType = RingRecipe
    def likeKey = new RingRecipe(name, requiredLevel)

    type CraftableItemType = Ring
    protected def newInstance(id: Long) = new Ring(id, name, requiredLevel)
}

I must admit, I'm not doing much pattern matching on these classes. I basically generate a case class because it saves time ;)

Solution?

Ken

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Hmm, repetition is not completely eliminated, but maybe this helps you a bit saving keystrokes ;-)

abstract class GearRecipe[A, B](
recipeConstructor: (String, Int) => A,
itemConstructor: (Long, String, Int) => B
) {
def name: String
def requiredLevel: Int
def likeKey = recipeConstructor(name, requiredLevel)
def newInstance(id: Long) = itemConstructor(id, name, requiredLevel)
}

case class WeaponRecipe(name: String, requiredLevel: Int)
extends GearRecipe[WeaponRecipe, Weapon](WeaponRecipe(_,_), Weapon(_,_,_))

case class RingRecipe(name: String, requiredLevel: Int)
extends GearRecipe[RingRecipe, Ring](RingRecipe(_,_), Ring(_,_,_))

case class Weapon(id: Long, name: String, requiredLevel: Int)
case class Ring(id: Long, name: String, requiredLevel: Int)

object Main {
def main(args: Array[String]) = {
val recipe = new WeaponRecipe("sword", 21)
recipe.likeKey
recipe.newInstance(42L)
}
}

Am 29.04.2010 um 23:45 schrieb Ken Egervari:

> Yeah, unfortunately, they both have to be case classes ;)
>
> I wonder if I could just remove these recipe subclasses altogether. I think that's what I have to do :/
>
> Ken
>
>
> On Thu, Apr 29, 2010 at 5:26 PM, Kevin Wright wrote:
> RingRecipe looks fine but shouldn't be subclassing anything that's also a case class.
> It looks as though GearRecipe *is*, which is causing the warning.
>
>
> On 29 April 2010 21:52, Ken Egervari wrote:
> Hi,
>
> I'm getting a compiler warning that looks like this:
>
> warning: case class `class RingRecipe' has case class ancestor `class GearRecipe'. This has been deprecated for unduly complicating both usage and implementation. You should instead use extractors for pattern matching on non-leaf nodes.
>
> I get this with the following code (and much like it):
>
> case class RingRecipe(
> override val name: String,
> override val requiredLevel: Int
> ) extends GearRecipe(name, requiredLevel) {
> type ItemType = RingRecipe
> def likeKey = new RingRecipe(name, requiredLevel)
>
> type CraftableItemType = Ring
> protected def newInstance(id: Long) = new Ring(id, name, requiredLevel)
> }
>
> I must admit, I'm not doing much pattern matching on these classes. I basically generate a case class because it saves time ;)
>
> Solution?
>
> Ken
>
>
>

On Thu, Apr 29, 2010 at 10:53:07PM +0100, Kevin Wright wrote:
> You can get 100% of case class functionality without actually being a
> case class.

(*) Actual value of 100 may vary. (Sealed.)

Sorry, Paul, could you explain?

On Thu, Apr 29, 2010 at 6:20 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Thu, Apr 29, 2010 at 10:53:07PM +0100, Kevin Wright wrote:
> You can get 100% of case class functionality without actually being a
> case class.

(*) Actual value of 100 may vary.  (Sealed.)

--
Paul Phillips      | Eschew mastication.
Stickler           |
Empiricist         |
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

'tis true!
If you have:- a bunch of classes inheriting from the same parent- all defined in the same file- and said parent is sealed

Then the compiler will warn if you have a pattern match block that doesn't check for all of said case classes.

Does this even work if the parent is also a case class?  What if you have a case class derived from a case class derived from a sealed class? (yikes!)  The permutations are scary, and the wisdom in deprecating case class inheritance is becoming clearer and clearer.


On 30 April 2010 05:16, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Sorry, Paul, could you explain?

On Thu, Apr 29, 2010 at 6:20 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Thu, Apr 29, 2010 at 10:53:07PM +0100, Kevin Wright wrote:
> You can get 100% of case class functionality without actually being a
> case class.

(*) Actual value of 100 may vary.  (Sealed.)

--
Paul Phillips      | Eschew mastication.
Stickler           |
Empiricist         |
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Yesturday, I got my program to work without any of the subclasses at all. GearRecipe actually extended from another class called Recipe, which I made have a type parameter, ItemType. Gear had many subclasses, but I ditched those too. So now Recipes of any item type are written Recipe[MyItemSubClass] and GearRecipe is a special case, which is really Recipe[Gear].

This makes it easier to instantiate Gear objects from within a GearRecipe because I just added a type enumeration called GearType to the Gear object.

This also got rid of all my case class inheritance. I had to make sure Recipe was not a case class. It previously was, because I needed to do pattern matching on it. Now I just do isInstanceOf[] until I add the necessary faux methods to make it work with pattern matching.

GearRecipe is now the only concrete case class as the leaf in the Recipe[Item] tree.

I understand why Scala removed the ability to inherit from case classes, but it makes programming much harder for lazy programmers like me, mainly because of the implementation of equals() and hashCode(). If there was a way to point to an internally "to be built" implementation at compile time, I'd be all for that. Case classes seemed to be a godsend for that reason, and I don't think Idea can generate them yet (maybe they can now though).

Ken


On Fri, Apr 30, 2010 at 2:31 AM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:

'tis true!
If you have:- a bunch of classes inheriting from the same parent- all defined in the same file- and said parent is sealed

Then the compiler will warn if you have a pattern match block that doesn't check for all of said case classes.

Does this even work if the parent is also a case class?  What if you have a case class derived from a case class derived from a sealed class? (yikes!)  The permutations are scary, and the wisdom in deprecating case class inheritance is becoming clearer and clearer.


On 30 April 2010 05:16, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Sorry, Paul, could you explain?

On Thu, Apr 29, 2010 at 6:20 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Thu, Apr 29, 2010 at 10:53:07PM +0100, Kevin Wright wrote:
> You can get 100% of case class functionality without actually being a
> case class.

(*) Actual value of 100 may vary.  (Sealed.)

--
Paul Phillips      | Eschew mastication.
Stickler           |
Empiricist         |
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Case classes delegate to the _hashcode and _equals methods as defined in scala.runtime.ScalaRunTime
You too can take advantage of this behaviour, so long as you're willing to subclass Product

On 30 April 2010 11:52, Ken Egervari <ken [dot] egervari [at] gmail [dot] com> wrote:

Yesturday, I got my program to work without any of the subclasses at all. GearRecipe actually extended from another class called Recipe, which I made have a type parameter, ItemType. Gear had many subclasses, but I ditched those too. So now Recipes of any item type are written Recipe[MyItemSubClass] and GearRecipe is a special case, which is really Recipe[Gear].

This makes it easier to instantiate Gear objects from within a GearRecipe because I just added a type enumeration called GearType to the Gear object.

This also got rid of all my case class inheritance. I had to make sure Recipe was not a case class. It previously was, because I needed to do pattern matching on it. Now I just do isInstanceOf[] until I add the necessary faux methods to make it work with pattern matching.

GearRecipe is now the only concrete case class as the leaf in the Recipe[Item] tree.

I understand why Scala removed the ability to inherit from case classes, but it makes programming much harder for lazy programmers like me, mainly because of the implementation of equals() and hashCode(). If there was a way to point to an internally "to be built" implementation at compile time, I'd be all for that. Case classes seemed to be a godsend for that reason, and I don't think Idea can generate them yet (maybe they can now though).

Ken


On Fri, Apr 30, 2010 at 2:31 AM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:

'tis true!
If you have:- a bunch of classes inheriting from the same parent- all defined in the same file- and said parent is sealed

Then the compiler will warn if you have a pattern match block that doesn't check for all of said case classes.

Does this even work if the parent is also a case class?  What if you have a case class derived from a case class derived from a sealed class? (yikes!)  The permutations are scary, and the wisdom in deprecating case class inheritance is becoming clearer and clearer.


On 30 April 2010 05:16, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Sorry, Paul, could you explain?

On Thu, Apr 29, 2010 at 6:20 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Thu, Apr 29, 2010 at 10:53:07PM +0100, Kevin Wright wrote:
> You can get 100% of case class functionality without actually being a
> case class.

(*) Actual value of 100 may vary.  (Sealed.)

--
Paul Phillips      | Eschew mastication.
Stickler           |
Empiricist         |
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Hi,
Can't find the class scala.runtime.ScalaRunTime in the scaladocs. Is this intended or it's a bug in the docs?
Regards,Germán.
On Fri, Apr 30, 2010 at 8:21 AM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:

Case classes delegate to the _hashcode and _equals methods as defined in scala.runtime.ScalaRunTime
You too can take advantage of this behaviour, so long as you're willing to subclass Product

On 30 April 2010 11:52, Ken Egervari <ken [dot] egervari [at] gmail [dot] com> wrote:

Yesturday, I got my program to work without any of the subclasses at all. GearRecipe actually extended from another class called Recipe, which I made have a type parameter, ItemType. Gear had many subclasses, but I ditched those too. So now Recipes of any item type are written Recipe[MyItemSubClass] and GearRecipe is a special case, which is really Recipe[Gear].

This makes it easier to instantiate Gear objects from within a GearRecipe because I just added a type enumeration called GearType to the Gear object.

This also got rid of all my case class inheritance. I had to make sure Recipe was not a case class. It previously was, because I needed to do pattern matching on it. Now I just do isInstanceOf[] until I add the necessary faux methods to make it work with pattern matching.

GearRecipe is now the only concrete case class as the leaf in the Recipe[Item] tree.

I understand why Scala removed the ability to inherit from case classes, but it makes programming much harder for lazy programmers like me, mainly because of the implementation of equals() and hashCode(). If there was a way to point to an internally "to be built" implementation at compile time, I'd be all for that. Case classes seemed to be a godsend for that reason, and I don't think Idea can generate them yet (maybe they can now though).

Ken


On Fri, Apr 30, 2010 at 2:31 AM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:

'tis true!
If you have:- a bunch of classes inheriting from the same parent- all defined in the same file- and said parent is sealed

Then the compiler will warn if you have a pattern match block that doesn't check for all of said case classes.

Does this even work if the parent is also a case class?  What if you have a case class derived from a case class derived from a sealed class? (yikes!)  The permutations are scary, and the wisdom in deprecating case class inheritance is becoming clearer and clearer.


On 30 April 2010 05:16, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Sorry, Paul, could you explain?

On Thu, Apr 29, 2010 at 6:20 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Thu, Apr 29, 2010 at 10:53:07PM +0100, Kevin Wright wrote:
> You can get 100% of case class functionality without actually being a
> case class.

(*) Actual value of 100 may vary.  (Sealed.)

--
Paul Phillips      | Eschew mastication.
Stickler           |
Empiricist         |
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

This could be a use case for trait parameters.

On Fri, Apr 30, 2010 at 7:21 AM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:

Case classes delegate to the _hashcode and _equals methods as defined in scala.runtime.ScalaRunTime
You too can take advantage of this behaviour, so long as you're willing to subclass Product

On 30 April 2010 11:52, Ken Egervari <ken [dot] egervari [at] gmail [dot] com> wrote:

Yesturday, I got my program to work without any of the subclasses at all. GearRecipe actually extended from another class called Recipe, which I made have a type parameter, ItemType. Gear had many subclasses, but I ditched those too. So now Recipes of any item type are written Recipe[MyItemSubClass] and GearRecipe is a special case, which is really Recipe[Gear].

This makes it easier to instantiate Gear objects from within a GearRecipe because I just added a type enumeration called GearType to the Gear object.

This also got rid of all my case class inheritance. I had to make sure Recipe was not a case class. It previously was, because I needed to do pattern matching on it. Now I just do isInstanceOf[] until I add the necessary faux methods to make it work with pattern matching.

GearRecipe is now the only concrete case class as the leaf in the Recipe[Item] tree.

I understand why Scala removed the ability to inherit from case classes, but it makes programming much harder for lazy programmers like me, mainly because of the implementation of equals() and hashCode(). If there was a way to point to an internally "to be built" implementation at compile time, I'd be all for that. Case classes seemed to be a godsend for that reason, and I don't think Idea can generate them yet (maybe they can now though).

Ken


On Fri, Apr 30, 2010 at 2:31 AM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:

'tis true!
If you have:- a bunch of classes inheriting from the same parent- all defined in the same file- and said parent is sealed

Then the compiler will warn if you have a pattern match block that doesn't check for all of said case classes.

Does this even work if the parent is also a case class?  What if you have a case class derived from a case class derived from a sealed class? (yikes!)  The permutations are scary, and the wisdom in deprecating case class inheritance is becoming clearer and clearer.


On 30 April 2010 05:16, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Sorry, Paul, could you explain?

On Thu, Apr 29, 2010 at 6:20 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Thu, Apr 29, 2010 at 10:53:07PM +0100, Kevin Wright wrote:
> You can get 100% of case class functionality without actually being a
> case class.

(*) Actual value of 100 may vary.  (Sealed.)

--
Paul Phillips      | Eschew mastication.
Stickler           |
Empiricist         |
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

If the sealed parent is a case class the compiler won't warn you? Why?
And why does that mean that you can't really "get 100% of case class functionality without actually being a
case class"?


On Fri, Apr 30, 2010 at 2:31 AM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:

'tis true!
If you have:- a bunch of classes inheriting from the same parent- all defined in the same file- and said parent is sealed

Then the compiler will warn if you have a pattern match block that doesn't check for all of said case classes.

Does this even work if the parent is also a case class?  What if you have a case class derived from a case class derived from a sealed class? (yikes!)  The permutations are scary, and the wisdom in deprecating case class inheritance is becoming clearer and clearer.


On 30 April 2010 05:16, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:

Sorry, Paul, could you explain?

On Thu, Apr 29, 2010 at 6:20 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:

On Thu, Apr 29, 2010 at 10:53:07PM +0100, Kevin Wright wrote:
> You can get 100% of case class functionality without actually being a
> case class.

(*) Actual value of 100 may vary.  (Sealed.)

--
Paul Phillips      | Eschew mastication.
Stickler           |
Empiricist         |
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda