Re: Method overrides and covariant return types

Okay, I take back my request that the warning should be changed to an error. See
below.

Quoting Daniel Bonniot <[email protected]>:
> >There is still one problem. If you have overloaded a method in such a way
> that>it _could_ override another method, then the compiler _forces_ the
> overriding.
> >That is, I can't find a way to say "This method does not override a method
> with the same name and with contravariant parameters," like in 
> f.doSomethingElse(B) below.
> >  
> >
> I think that the current behaviour is desirable. Having a method that 
> could override another, but actually performs an action that is not 
> acceptable for the original method is plain confusing. In that case, you 
> are most likely better off making the difference obvious in choosing a 
> descriptive distinct name for the new method.

But this is a demonstration of one of the key motivations for introducing the
"override" keyword. You (Daniel) previously wrote on this list, in the
"inheritence bug" thread:

>The problem is described in the C# article you linked to. If you
>later introduce a method with the same name in an imported package,
>you will suddenly override it silently, while you had no knowledge
>of that method when you wrote your implementation. So there is
>absolutely no guarantee that your implementation is meaningful for
>that method, that it fullfills its contract, ...

If the current behavior is "emit the warning and then treat the method as not
overriding anything" then I admit that the current behavior makes a lot of
sense, because then it is reasonable to say "Yes, I wrote what I meant, don't
show me this warning." But if the behavior is "emit the warning and then act as
though the 'override' keyword was there" then that is a serious problem. I think
it only makes sense to say that a method never overrides another method unless
the 'override' keyword is present; i.e. no implicit overrides, for the reason
you gave (directly above).

This problem arises in practice by the fact that many method names are used over
and over again. For example, "add," "remove," "isEnabled," "log."

> 
> >override B doSomething(B a) { }
> >// This isn't supposed to override anything
> >void doSomethingElse(B b) { }
> >  
> >
> (anyway, this is supposed to give you a warning or error. so you would 
> need an explicit way about _not_ overriding...)
       
- Brian






-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click