Surprisingly the case classes in Scala don't follow the recommendation in Chapeter 28, e.g.:

trait Points {}
 
case class Point( x : Int, y : Int ) extends Points {}
 
case class Point3D2( override val x : Int, override val y : Int, z : Int ) extends Point( x, y ) {}
 
    val p = new Point( 2, 1 )
    val p3D2 = new Point3D2( 2, 1, 0 )
    val p23D2 = new Point3D2( 2, 1, 2 )
    println( "Option 2e - equals and Point3D2 extends Point (no s)" )
    println( p == p )
    println( p == p3D2 )
    println( p3D2 == p )
    println( p3D2 == p3D2 )
    println( !(p == p23D2) )
    println( !(p3D2 == p23D2) )

Gives:

Option 2e - equals and Point3D2 extends Point (no s)
true
true
false
true
false
true

> >

> > scala> implicit def convert(rat: Rational) =
> > rat.numer.toDouble / rat.denom.toDouble
> > convert: (Rational)Double
> > 

>
> Unfortunately then the Int case no longer produces the
> desired result:
>
> 4*(new Rational(1/3))
>
> 1.3333...
>
Oops. I guess I should have tested better!

I'll go back to the drawing board.

Hi Howard,

> Surprisingly the case classes in Scala don't follow the
> recommendation in Chapeter 28, e.g.:
>
Yes, that bugged me too. I did bring it up here:

http://www.scala-lang.org/node/987#comment-4558

And was told it had been brought up before. They may drop case class inheritance in 2.8, but even if they do, you'll still be able to subclass a case class with a regular class. So the problem still holds. I think case classes should get a canEqual method. I'll bring it up again with Martin next week at JavaOne. Howard, will you be at JavaOne this year?

[snip]
> And was told it had been brought up before. They may drop
> case class inheritance in 2.8, but even if they do, you'll
> still be able to subclass a case class with a regular
> class. So the problem still holds. I think case classes
> should get a canEqual method. I'll bring it up again with
> Martin next week at JavaOne. Howard, will you be at
> JavaOne this year?

Unfortunately I can't make JaveOne. But I will be in Switzerland, for my day job (not Scala related), from August to January, so if you are going over maybe we could meet up there.

Howard,

> Chapter 28 of the Scala Book is great, particularly since
> I am a fan of multiple dispatch and the suggested solution
> is to hand code multiple dispatch :).

So, just for kicks, any thoughts on how PEC could some day work with Scala?

PEC could be rewritten to work with Scala, but it would be a lot of work. In particular I make extensive use of the Javassist library that unfortunately doesn't work with Scala.

Because Scala doesn't have a direct translation between a class definition and a class file (strictly Java doesn't have a direct translation for inner classes but it is close), it would probably by easier in Scala to break into the compiler and modify the AST rather than modify the class file byte codes (which is what Javassist does). This breaking into the compiler might be easy, you can do this in Java already using the annotation processor and casting the unmodifiable AST you get into a modifiable AST (I guess something similar will work with the Scala compiler).