On Tue, 30 Aug 2011 11:40:40 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 8/30/11 7:45 AM, Steven Schveighoffer wrote:
On Tue, 30 Aug 2011 08:26:17 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
