On Tue, 30 Aug 2011 13:39:35 -0400, Timon Gehr <timon.g...@gmx.ch> wrote:
On 08/30/2011 07:16 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 13:06:02 -0400, Timon Gehr <timon.g...@gmx.ch>
wrote:
On 08/30/2011 06:43 PM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 12:29:59 -0400, Andrei Alexandrescu
<seewebsiteforem...@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.
I know. What I'm saying is it's feasible for the nature of an interface
to be such that you don't have inheritance chains of more than one class.
Typically a change like this is done for entire libraries where one person
is in control of all the implementing classes, and the author knows the
interface to abstract class change will not be a burden.
Technically, the problems created would make such a change not feasible,
not just annoying. I'm talking about cases where it is feasible.
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
}
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
