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

[Steven Schveighoffer]

On Tue, 30 Aug 2011 17:41:46 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Tuesday, August 30, 2011 11:35 Steven Schveighoffer wrote:
>> On Tue, 30 Aug 2011 14:30:42 -0400, Timon Gehr <timon.gehr at gmx.ch>  
>> wrote:
>> > On 08/30/2011 07:50 PM, Steven Schveighoffer wrote:
>> >> We could find cases like this all day.
>> >>
>> >> Make I a class, and this problem also occurs.
>> >>
>> >> Without the compiler having access to the *changes* it cannot be  
>> perfect
>> >> in detecting refactoring errors.
>> >>
>> >> -Steve
>> >
>> > Chances are that it will detect more errors if "override" actually  
>> means
>> > override.
>>
>> Is it just the name? What if it was implement? or override_or_implement?
>> Would that make it "detect more errors"?
>>
>> I can't see how finding more bugs is a bad thing, regardless of what the
>> name of the keyword is.
>
> I think that if you wanted full control such that a function is always
> overriding when you want it and never when you don't want it to and such  
> that
> it's always implementing when you want it to and never when you don't  
> want it
> to, then we're going to need to add implements (or more likely,  
> @implements)
> on top of override. The two concepts are similar but separate, and  
> overloading
> override to do both just creates a separate set of problems (e.g. you  
> thought
> that a function was overriding a base class function and implementing an
> interface and now it's just implementing an interface, so you don't  
> catch the
> fact that the base class function is gone unless you were explictly  
> calling it
> in the derived function). So, if we were to make a change, I'd argue for
> adding @implements rather than altering how override works.

Again, if the intention of your override keyword is to override all base  
class/interface functionality, who cares what changes underneath?  As long  
as the hook is still present, there is no error when the base class  
disappears.  I see zero value for separating @implements from override.

The main purpose of override is to say "I expect that some base class (or  
interface) declares this function, and I want to write an implementation  
for it".  I agree that override for interfaces is not necessary in some  
cases (for example, if you write the incorrect signature, it's an error  
anyway), but there are some cases where it helps.  I don't see what the  
*harm* is in using it, it's already there.

-Steve