Personnally, I would like override to be used when implementing
interfaces too, because there is really some hooking happening (and
thus hijacking risks), regardless of the presence of a previous method
or not.
If the problem is that you may have a method witch overrides an abstract
class CÂ when the overide keyword was meant for an interface before
restructuring, well, that can happen. Let's take your example:
interface I { void foo(); }
class C:I { override void foo(); }
-> becomes ->
interface I { void foo(); }
class B:I { override void foo(); }
class C:B { override void foo(); } // left by mistake
Maybe foo was left by mistake, but from the beginning (before creating
class B), the method was meant to override I, so it must not be that
bad. Moreover, the override keyword is present, so you should be careful
when looking at class C. This seems to me to be less important that
implementing an interface by mistake (apparently not to everybody).
Anyway this could happen anyway if 'I' was an abstract class at the
beginning.
If you are concerned by knowing exactly what you override (ant it's a
good thing) when you use the override keyword, the langage should help
you with an argument to the override attribute:
interface I { void foo(); }
class B:I { override(I) void foo(); }
class C:B { override(I) void foo(); } // left by mistake
^ error: foo() is overriding B.foo()
abstract class B2:I { }
class C2:B2 { override(I) void foo(); } // would works fine
class C3:B2 { override(B) void foo(); }
^ error: foo() is overriding I.foo()
The argument to override should be optionnal, so that every good code
will not be broken.
Cheers.
--
Christophe Travert
