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

Steven Schveighoffer schveiguy at yahoo.com
Tue Aug 30 12:00:11 PDT 2011


On Tue, 30 Aug 2011 14:56:46 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 08/30/2011 08:35 PM, 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 am saying:
>
> override_or_implement naturally will detect less errors because it is  
> less specific. Based on context it either means "do nothing special" or  
> "override that method". (that is the current behavior of "override" of  
> course)
>
> Renaming the keyword would make its current meaning more explicit, it  
> wouldn't make it detect more errors.

I mean if override was required for reimplementing base class functions  
and required for implementing interface functions.

The errors it doesn't detect is when an interface changes to a class, and  
for some reason you no longer want to override, um... I have no idea what  
errors it wouldn't detect.

-Steve


More information about the Digitalmars-d mailing list