When does final mean "maybe, kinda, sorta" ?

[Steve Horne]

On Tue, 23 Jan 2007 00:26:10 -0800, kris <foo at bar.com> wrote:

>Steve Horne wrote:
>[snip]
>
>> And adding a new private member to a base class should not
>> break any derived classes that might happen to already use the same
>> signature for a (private or public) method, especially since you may
>> have no control or even knowledge of those derived classes.
>
>Given that, I'd imagine you'd be a proponent of making 'override' a 
>required keyword? After all, not requiring it will likely lead to the 
>same type of problem when a base-class method is removed.
>
>Yet, judging by past record, override is unlikely to ever be required.

Override should only be specified when the intent is to override, IMO.

If adding a new public/protected method to a base class results in its
accidentally being overridden by a pre-existing conflicting
derived-class method, clearly that's bad. So...

1. Specifying override on a method that doesn't override any base
   class method should be an error.
2. Failing to specify override on a method that does override a base
   class public/protected method should be an error.

I thought that was what D does anyway, and for that matter that it was
the whole point of the override keyword - but, as I said, I'm more in
C++ mode ATM (and haven't been using D that long anyway).

Presumably removal of an overridden base-class method would be covered
by case 1, which is why you are saying it should be required, and
therefore I assume this case 1 error doesn't occur. Which gets a
reading on my odd-ometer.

Mind you, removing a public/protected interface from a published class
should be a pretty unusual thing to do. Getting people dependent on an
interface and then just taking it away without warning is more than a
bit dodgy. The possibility of problems shouldn't really come as a
surprise.

It's similar to the rule for COM interfaces - extending is OK,
different implementations OK, but compatibility with previously
published interfaces should be maintained (though the main breaker of
that rule seems to be Microsoft itself).

When adding new methods creates problems, there is genuine reason why
you wouldn't necessarily anticipate the problems - you can't
necessarily know which new method signatures would be safe and which
would cause conflicts. So case 2 above is much more important to me
than case 1, since it catches non-obvious errors rather than errors I
should have anticipated.

My main reason for case 1 is that programmers shouldn't add override
flags to every single method just to save thinking about it, since it
defeats the whole point of the keyword. But it's just so obviously
grossly bad style anyway, like not bothering with indentation or
calling your variable var1, var2, var3 and so on.


Going off on a tangent, a way of saying 'OK, this is the same
signature as a base class method, but this is independent, and gets a
separate slot in the virtual table' might be a good idea. Perhaps an
alternate application of the 'new' keyword. Or maybe there already is
a flag for this, and I forgot.

The idea is that, when a derived class developer gets a conflict with
a new base class interface, there's a quick (if slightly dirty) fix.
The derived class can keep its (possibly also published) interface
intact. Anyone needing the base class version can use a call notation
indicating that, or else cast to the base class - less than ideal, but
maybe better than forcing the derived class developers into renaming
and refactoring, and the resulting interface change.

-- 
Remove 'wants' and 'nospam' from e-mail.