sobreescribir métodos en Scala

Question

Scala le permite anular un método de 2 formas legales:

Dada superclase:

class A { 
    def a = "A" 
} 

Podemos reemplazar el método "a" por:

class B extends A { 
    override def a = "B" 
} 

y

class B extends A { 
    override def a() = "B" 
} 

ambos parecen sobrepasar ide el método "a" correctamente. ¿Cuál es la decisión de diseño detrás de esto? ¿Por qué permitir "a()" en B para anular "a" en A?

Answer 1

Esto no siempre ha sido el caso (desde el registro de cambios de the language specification):

Scala versión 2.0 también relaja las reglas de preponderante sobre el listas de parámetros vacíos. La definición revisada de Miembros coincidentes (§5.1.3) hace que sea ahora posible reemplazar un método con una lista explícita, pero vacío parámetro () con un método sin parámetros, y vice versa .

Tiene razón en que esto parece una decisión de diseño extraña, dado que existen diferencias observables entre los métodos sin parámetros y los que tienen listas de parámetros vacías. Por ejemplo, suponga que tiene la siguiente:

class A { def a = "A" } 
class B extends A { override def a = "B" } 
class C extends A { override def a() = "C" } 

Ahora podemos escribir la siguiente, como era de esperar:

scala> (new B).a 
res0: java.lang.String = B 

scala> (new C).a 
res1: java.lang.String = C 

Y esto:

scala> (new C).a() 
res2: java.lang.String = C 

Pero no esto:

scala> (new B).a() 
<console>:10: error: not enough arguments for method apply: (index: Int)Char in class StringOps. 
Unspecified value parameter index. 
       (new B).a() 

Así que Scala hace un disti nction entre los dos, que obviamente debe reflejarse en el bytecode. Supongamos que se elaborarán las siguientes:

class A { def a = "A" } 
class B extends A { override def a = "B" } 

y luego ejecutar:

javap -verbose B > noArgList.txt 

a continuación, cambiar el código para esto:

class A { def a = "A" } 
class B extends A { override def a() = "B" } 

recompilación, y ejecute:

javap -verbose B > emptyArgList.txt 

Y finalmente verifique las diferencias:

< MD5 checksum 88aeebf57b645fce2b2fcd2f81acdbbd 
--- 
> MD5 checksum 3733b3e4181b4b2f4993503d4c05770e 
32c32 
< #18 = Utf8    }1A! 
           \t\t!ICaT-9uszaE\r)\"a\tI!!\"1Q!Dg 
jiz\"a\tAQ!BY\t!Y             G.Y11bU2bY|%M[3di\")C%1A(
       /A$H3)!dGYtwMCQM^1\nyI\"AB*ue&tw\r 
--- 
> #18 = Utf8    }1A! 
           \t\t!ICaT-9uszaE\r)\"a\tI!!\"1Q!Dg 
jiz\"a\tAQ!BY\t!             G.Y11bU2bY|%M[3di\")C%1A(
       /A$H3)!dGYtwMCQM^1\nyI\"AB*ue&tw\r 

lo que hay una diferencia, las dos versiones tienen valores diferentes para el ScalaSignature anotación.

En cuanto a por qué el cambio se hizo en Scala 2.0: la especificación observa que permite esto:

class C { 
    override def toString: String = ... 
} 

Mi suposición es que los diseñadores del lenguaje simplemente no ven una razón para exigir a los usuarios recordar qué enfoque utilizan los métodos anulados en casos como este.