method returning child, doesn't overrides declared method returning parent

[Timon Gehr]

On 08/30/2011 01:48 PM, Marco Leise wrote:
> Am 29.08.2011, 22:24 Uhr, schrieb Jonathan M Davis <jmdavisProg at 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.