Aladdin - Scala Bugtracking
[#145] project: compiler priority: medium category: bug
submitter assigned to status date submitted
Matthias Martin fixed 2003-09-16 14:25:06.0
subject Specific super class reference yields IncompatibleClassChangeError
code 
trait J[T] {
  def foo(x: T): Int;
}
trait I[T] with J[T] {
  override def foo(x: T): Int = super[J].foo(x) + 1;
}
class C {
  def foo(x: Int): Int = x;
}
class D extends C with I[Int];
object T with Executable {
  System.out.println((new D).foo(3));
}
what happened 
Compiles, but at runtime we get:

Exception in thread "main" java.lang.IncompatibleClassChangeError
        at D$class.foo(Y.scala:5)
        at D$class.foo(Y.scala:5)
        at T$.(Y.scala:12)
        at T$.(Y.scala)
        at T.main(Y.scala)
what expected Compiles & runs.
[back to overview]
Changes of this bug report
Michel  edited on  2003-09-30 10:59:27.0

In my opinion the code above should be rejected by the compiler, for the following reason: we have two kinds of super in Scala.

The first kind (written simply super) is used to refer to methods of the superclass, which is unknown at the point where the reference appears (because of mixins, as discussed in another "bug" that I incorrectly filed). I now agree that it's fine that these references designate abstract methods, provided that the class containing such a reference is used only as a mixin and its superclass contains appropriate definitions.

Ths second kind of super, which refers to methods of mixins (written super[mixin]), should IMO not be allowed to refer to abstract methods. The reason is that such references are really purely static: they refer to a specific method in a specific mixin. At the point where such a reference appear, you know exactly what method is referenced, and I fail to see through which mechanism this could later change. But please, Martin or Matthias, correct me if I'm wrong.

Martin  edited on  2003-10-08 20:48:25.0