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

[Jonathan M Davis]

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.

- Jonathan M Davis