On Tue, 30 Aug 2011 17:41:46 -0400, Jonathan M Davis <[email protected]>
wrote:
On Tuesday, August 30, 2011 11:35 Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 14:30:42 -0400, Timon Gehr <[email protected]>
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
