Re: Method overrides and covariant return types

>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 don't want to support writing methods that do not override while they 
could. As I explained earlier, this creates a confusing situation _for 
the caller of the method_.  It's easy enough to pick a different and 
descriptive name for the new method.

>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.
>  
>
By experience, we know that people _will_ write implicit overriding, and 
expect it to work, even though the documentation shows that method 
implementations have a different form. The habits are just too strong. 
That's why it's important to recognize this situation (and not silently 
ignore the overriding like we used to do). For the moment, you get a 
warning (that cannot be disabled, which is a good thing at this point, I 
agree). The good part about it being a warning is that it leaves the 
choice to the new user to first focus on other errors he might get. He 
knows that he will have to deal with the warning eventually, understand 
why it's there and how to make it disappear, but if he is already 
struggling with other points (being a newcomer), he can safely postpone 
that. Learning a new language is always some effort, so this can make 
the experience more gratifying (i could get my program to compile, and 
it runs well! now let's look at these warnings)


>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. 
>
Agreed. So the flag could decide whether to report a warning or not. 
Warnings should no be ignorable anyway.

>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).
>  
>
Agreed.

>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.
>  
>
You don't have to rename it. You could also use fully qualified method 
names to disambiguate them.

You seem to assume that if we decide to go for explicit overriding only, 
then we can allow non-overriding. I don't think so, for two reasons. The 
first is that this creates confusion. The second is that people _will_ 
write implicit overriding when they mean explicit, so they must be 
reported an error to fix that, rather than silently do something they 
don't want.

>I prefer the "third" option, where overloading is implicit and overriding is
>explicit. 
>
OK, so that's what you had it your mind above.

>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.
>  
>
You cannot at the same time say that a situation is potentially 
dangerous (and so report a warning) and that you still want to support 
it, unless there is a way to mark in the code that you really mean that. 
Otherwise you have warnings that you know you can ignore, which will 
eventually lead you to ignore warnings that are meaningful.

If both methods are defined in the same package, then you have the 
freedom not to name then identically from the start. If one of them is 
imported, then you can use a fully qualified name, which is indeed a way 
to state "yes, i really want a new method declared here, not an override".

Daniel



-------------------------------------------------------
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