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

[Timon Gehr]

On 08/30/2011 07:16 PM, Steven Schveighoffer wrote:
> On Tue, 30 Aug 2011 13:06:02 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 08/30/2011 06:43 PM, Steven Schveighoffer wrote:
>>> On Tue, 30 Aug 2011 12:29:59 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> On 8/30/11 11:06 AM, Steven Schveighoffer wrote:
>>>>> 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.
>>>>
>>>> From the cycle "deadpan answers": I think one should use "override"
>>>> when one wants to override.
>>>
>>> Then your description of cases where override helps prevent bugs should
>>> reflect that:
>>>
>>> (a) User thinks she overrides a specific method but instead introduces a
>>> new one.
>>>
>>> (b) User thinks she introduces a new method but instead overrides one.
>>>
>>> I consider implementing an interface method to be hooking, since you are
>>> hooking calls from said interface.
>>>
>>> I guess if we want to avoid solving all hooking problems, even those
>>> where one does not intend to implement an interface, but accidentally
>>> does, or introduce large annoyances where someone changes a widely used
>>> interface to an abstract class, then I guess the status quo is good.
>>>
>>> -Steve
>>
>> I don't think that you can change a widely used interface into an
>> abstract class and not introduce annoyances much larger than override
>> is capable of creating.
>
> interface I
> {
> int foo();
> void bar();
> }
>
> ->
>
> interface _I
> {
> int foo();
> void bar();
> }
>
> abstract class I : _I
> {
> int foo() { return 0; }
> }
>
> Now, everywhere I was implemented before has to change all their
> implementations of foo() to override, just to compile.
>
> There may be some cases where classes already had a base class, but it
> depends on the context of where I is implemented.

That is what I meant.

> However, in 100% of
> the cases, putting override on each implementation of foo does *not*
> result in a bug.

I agree.

>
> My point is, what "bug" is it preventing by rejecting override when
> implementing an interface? The only "bug" I see is that you didn't put
> override in the signature. That translates to an annoyance, not a real bug.

This one:

interface I{
     void method1();
     void method2();
     void method3();
}

class C: I{
     override void method1(){ ... }
     override void method2(){ ... }
     override void method3(){ ... }
}

=> // refactoring implementations of I in C to abstract class D

interface I{
     void method1();
     void method2();
     void method3();
}

abstract class D: I{
     override void method1(){ ... }
     override void method2(){ ... }
     override void method3(){ ... }
}

class C: D{
     // left method2() inside class C by accident
     override void method2(){ ... } // override makes compiler shut up
}


>
>> How does the status quo prevent implementing interface methods by
>> accident?
>
> It doesn't. That was my point.
>
Oh, I am sorry. I misread your sentence.