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

[Steven Schveighoffer]

On Tue, 30 Aug 2011 07:04:27 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Tuesday, August 30, 2011 06:47:03 Steven Schveighoffer wrote:
>> On Mon, 29 Aug 2011 16:24:46 -0400, Jonathan M Davis  
>> <jmdavisProg at gmx.com>
>>
>> wrote:
>> > On Monday, August 29, 2011 14:09 Mariusz Gliwiński wrote:
>> >> <code>
>> >> interface Interface {
>> >> Interface method();
>> >> }
>> >> class Class : Interface {
>> >> override Class method() {}
>> >> }
>> >> </code>
>> >>
>> >> DMD complains it isn't overriding. How should it be according to
>> >> specification, and how about making it legal?
>> >
>> > 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.
>>
>> Then this must be a bug?
>>
>> interface I
>> {
>>    void foo();
>> }
>>
>> class C : I
>> {
>>     override void foo(); // compiles
>> }
>>
>> I feel override should be *allowed* when implementing interface  
>> functions
>> (but not required).  Otherwise, you get into situations where a base  
>> class
>> decides to become abstract (doesn't implement a function), but a derived
>> class is specifying override (especially if override is required, as is
>> planned), if that's a compiler error, I think it's a useless error.
>
> I think that override belongs on functions which actually override base  
> class
> functions. It should be required when a function overrides a base class
> function, and it should be disallowed when it's on a function that  
> doesn't
> override a base class function. Interfaces have nothing to do with it.
>
> The whole point of override is to make sure that you know when your  
> function
> is or isn't overriding a base class function. Ff the base class changes,  
> then
> that's extremely relevant to the derived class, and it _should_ error  
> out if
> the function is no longer marked as it should be (be it that it has  
> override
> when it shouldn't or that it doesn't have it when it should). That way,  
> you
> never have functions which override when you didn't mean them to (e.g.  
> if a
> new function were added to one of its base classes), and you never have a
> function which _doesn't_ override when you mean it to (e.g. when a  
> function
> was removed from one or more of its base classes).

This argument has holes in it:

class A
{
    void foo();
}

class B : A
{
    version(newlyAddedBFoo)
       override void foo();
}

class C : B
{
    override void foo(); // does not see newly added B.foo
}

This will compile fine with or without the version enabled.  When you say  
override, you say "I don't care what came before me, I'm implementing this  
function."  Now, if B decided to make foo final, yeah, you should know  
about it.  But I don't see why override shouldn't simply work when  
overriding a not-yet-implemented function.

What about an abstract base method, should override be required?

class A
{
    void foo() {}
    abstract void foo2();
}

class B : A
{
    override void foo() {}
    override void foo2() {} // should override be rejected here?  What  
utility would an error give you?
}

At the end of the day, an interface is simply a completely abstract  
class.  It might even have some implementation via final or template  
functions, but it participates in virtual functions much the same way as  
classes do.

-Steve