On 08/30/2011 01:48 PM, Marco Leise wrote:
Am 29.08.2011, 22:24 Uhr, schrieb Jonathan M Davis <jmdavisp...@gmx.com>:
It's _not_ overriding. It's implementing an interface method. Those
are two
totally different things. And I think that it's horrible that Java
considers
implementing an interface method as overriding it. I'd _hate_ to see
that in
D.
- Jonathan M Davis
This design decision in Java isn't particularly bad I think. Look at how
dim the line is between an interface, an abstract class and a class.
Some languages use the notion of a fully abstract class for interfaces.
In case you implement one interface and it is somewhat internal you may
choose to provide some default implementations and turn it into an
abstract class.
At that point, probably everything breaks, because you cannot inherit
from multiple classes.
At this point you should add 'override' to the all
descendant classes that override these implementations.If override was
mandatory you could easily spot any methods that correspond to something
higher in the hierarchy (extended class / interface). What would you
argue for when you implement a method of an abstract class for example?
Does it override or implement?
If there already is an implementation, it overrides it, otherwise it
implements it. Easily spotting methods that correspond to something
higher in the hierarchy is achieved best with comments. (You actually
see to which parent of the class a method belongs.)
class C: I{
void somemethod() { }
/* interface I */
void someinterfacemethod() { }
void someotherinterfacemethod() { }
/* class Object */
override string toString() { }
}
But D is not Java and there are already cases of implicit interfaces
(Range). So it makes sense not to be overly verbose with interfaces in D.
I agree.
