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