问题
Based on a previous question, the following code compiles OK
trait Logger {
def log(msg: String): Unit
}
trait LoggerA extends Logger {
def log(msg: String) = ???
}
trait LoggerB extends Logger {
override def log(msg: String) = ???
}
class Logged1 extends LoggerA
class Logged2 extends LoggerB
class Logged3 extends LoggerA with LoggerB
The override
is not required in LoggerA
because there is no concrete implementation of log
in Logger
.
However if I remove the override
from LoggerB
it no longer compiles:
class Logged3 inherits conflicting members:
def log(msg: String): Nothing (defined in trait LoggerA) and
def log(msg: String): Nothing (defined in trait LoggerB)
(note: this can be resolved by declaring an `override` in class Logged3.)
Why is override
required in this specific case? Does specifying override
change the method or the class in some way?
回答1:
I guess it is specified by SLS 5.1.4 Overriding
If M′ is not an abstract member, then M must be labeled
override
. ... or both M and M′ override a third member M'' which is defined in a base class of both the classes containing M and M'.
Also in section 5.1.3 Class Members there is a similar use of override to OP
trait A { def f: Int }
trait B extends A { def f: Int = 1 ; def g: Int = 2 ; def h: Int = 3 }
trait C extends A { override def f: Int = 4 ; def g: Int }
trait D extends B with C { def h: Int }
thus at least it does seem a specified behaviour.
Based on fr_andres' answer and Learning Scala, Chapter 9. Objects, Case Classes, and Traits
a class extending class A and traits B and C is actually extending one class, which extends another class, which extends another class, when compiled to the .class binary file.
which due to linearization implies effectively
LoggerA (has concrete log)
^
|
LoggerB (also has concrete log)
^
|
Logged3
and override
is necessary when overriding a concrete implementation.
来源:https://stackoverflow.com/questions/66184225/why-is-override-sometimes-required-for-an-abstract-method