Re: Method overrides and covariant return types

Hi Daniel,

Quoting Daniel Bonniot <[email protected]>:
> >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." 
>
> How would you say that you don't want to see a warning for this specific 
> case?

If implicitly overriding is never done, then it is safe to compile with warnings
disabled, because this warning is basically "Hmm, we are guessing that a lot of
people would have wanted this method to override some other one, but since you
omitted the 'override' keyword, we assume that you wrote exactly what you meant.
But, are you sure?" I.e. it is basically just speculating that you might have
made a typo, similarly to the way that Jikes now emits lint-like warnings.

If implicit overriding is allowed, then it is basically never safe to compile
with warnings disabled, because the message is basically "hey, we are sure you
forgot the 'override' keyword so we will just pretend you put 'override' in
there. We hope that is what you meant." That is not safe, IMO.

> >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).
> >
> That's the behaviour. The reason I gave is why there is a warning in the 
> first place. The compiler detects that there is something going on, and 
> tells you about it, asking you to solve the problem. A warning is not 
> much different from an error. In both cases you should do something 
> about it.

> Now I think that in the long term there are two options: either we 
> acknoledge that some people don't want implicit overriding, while some 
> are perfectly comfortable with it, and we provide an option for users to 
> chose. Or we enforce the explicit style, and then the warning can be 
> made an error. The warning is just a middle ground to start with, and 
> gather experience in this area.

I don't like the idea that some source code can be either valid (no errors) or
invalid (produces compiler errors) depending on a compiler flag. And, I thought
that we all pretty much agreed that implicit overriding is a bad idea, for
reasons that you mentioned yourself (adding a method to an imported package that
 happens to have a "compatible" signature with one in the importing package). 

Similarly, the second option seems bad because it does not support the same use
case: imported package that  happens to have a "compatible" signature with one
in the importing package, your code will fail to compile. If the importing
package's method does not conform to the contract of the imported package's
method, then you have to rename it. But, this means that you have to change all
clients of the importing package (all packages that import it). This may not be
feasible.

I prefer the "third" option, where overloading is implicit and overriding is
explicit. It solves the issues that motivated the "overrides" keyword in the
first place, while the first two options do not. It is also very easy to explain
and easy to see in the code. In this case, detecting cases where you _might_
have meant to override is something for a Lint or PMD -like tool, possibly built
into the compiler, possibly external to the compiler.

- 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