2011-09-28 14 views
14

Perché è possibile sovrascrivere un metodo di parentesi vuote con un object?Sovrascrittura di un metodo con un oggetto

trait A { 
    def meth = {} 
    def meth_p() = {} 
} 

class B extends A { 
    object meth_p 
} // compiles 

override del metodo senza parentesi non compila:

class B1 extends A { 
    object meth 
} // does not compile 

nemmeno una delle seguenti combinazioni di lavoro (senza override modificatore):

class BX extends A { 
    // of course, each declaration should get its own class 
    def meth = {} 
    def meth_p() = {} 
    def meth() = {} 
    def meth_p = {} 
    val meth = {} 
    val meth_p = {} 
    // ... 
} 

È questo il comportamento documentato e utile ? Ho appena incontrato un insetto molto sottile a causa di questa forzatura accidentale.

risposta

6

Questo sicuramente sembra un bug. Se lo fai, il contrario è solo più strano.

class A { 
    object m { override def toString = "object m" } 
} 

class B extends A { 
    def m() = "def m" 
} 

scala> (new A).m 
res0: object A#m = object m 

scala> (new A).m() // doesn't compile 

scala> (new B).m 
<console>:10: error: ambiguous reference to overloaded definition, 
both method m in class B of type()java.lang.String 
and object m in class A of type object B#m 
match expected type ? 
       (new B).m 
        ^
scala> (new B).m() 
java.lang.VerifyError: class B overrides final method m.()LA$m$; 
     at java.lang.ClassLoader.defineClass1(Native Method) 
     at java.lang.ClassLoader.defineClassCond(Unknown Source) 
     at java.lang.ClassLoader.defineClass(Unknown Source) 
     at java.lang.ClassLoader.defineClass(Unknown Source) 
     at scala.tools.nsc.interpreter.AbstractFileClassLoader.findClass(AbstractFileClassLoader.scala:52) 
     at java.lang.ClassLoader.loadClass(Unknown Source) 
     at scala.tools.nsc.interpreter.AbstractFileClassLoader.scala$tools$nsc$util$ScalaClassLoader$$super$loadClass(AbstractFileClassLoader.scala:17) 
     at scala.tools.nsc.util.ScalaClassLoader$class.loadClass(ScalaClassLoader.scala:50) 
     at scala.tools.nsc.interpreter.AbstractFileClassLoader.loadClass(AbstractFileClassLoader.scala:17) 
     at java.lang.ClassLoader.loadClass(Unknown Source) 
     at .<init>(<console>:10) 
     at .<clinit>(<console>) 
     at .<init>(<console>:11) 
     at .<clinit>(<console>) 
     at $print(<console>) 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 
     at java.lang.reflect.Method.invoke(Unknown Source) 
     at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:704) 
     at scala.tools.nsc.interpreter.IMain$Request$$anonfun$14.apply(IMain.scala:920) 
     at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV$sp(Line.scala:43) 
     at scala.tools.nsc.io.package$$anon$2.run(package.scala:25) 
     at java.lang.Thread.run(Unknown Source) 
+0

Sì, questo sembra ancora più un bug. – Debilski

+0

https://issues.scala-lang.org/browse/SI-5429 – soc

Problemi correlati