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

Steven Schveighoffer schveiguy at yahoo.com
Tue Aug 30 09:06:46 PDT 2011


On Tue, 30 Aug 2011 11:40:40 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 8/30/11 7:45 AM, Steven Schveighoffer wrote:
>> On Tue, 30 Aug 2011 08:26:17 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 08/30/2011 07:13 AM, Timon Gehr wrote:
>>>> If there already is an implementation, it overrides it, otherwise it
>>>> implements it.
>>>
>>> That's pretty much it. The entire purpose of the "override" keyword is
>>> to prevent silent bugs of two kinds:
>>>
>>> (a) User thinks she hooks a specific method but instead introduces a
>>> new one.
>>>
>>> (b) User thinks she introduces a new method but instead hooks one.
>>>
>>> Override helps only in cases where otherwise a silent error would
>>> occur. If the compiler issues an error message without the help of
>>> override, override is unneeded and illegal. This is the case with
>>> interface and abstract methods - "override" is emphatically unneeded
>>> because the compiler/linker wouldn't allow the code anyway.
>>
>> Your (a) and (b) points seem to be pointing to a different conclusion --
>> that override should be required for interface methods.
>
> No, because the compiler rejects code that doesn't implement all methods  
> of an interface.

When I write code that derives from a base class, I'm declaring with  
override that I want to implement the base class' function.
When I write code that implements an interface, I'm declaring with  
override that I want to implement the interface's function.

I.e. I think I'm hooking a specific method, and not introducing a new one.

If override isn't required, wouldn't the lack of (b) mean you can get a  
silent bug when altering an interface?

For example:

interface I
{
}

class C : I
{
    void foo() {} // written expecting that I'm not hooking anything.
}

Now I is altered to say:

interface I
{
    void foo() {} // which is described as doing something completely  
different than C.foo
}

-Steve


More information about the Digitalmars-d mailing list