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

[Steve Horne]

On Mon, 22 Jan 2007 15:31:25 -0800, kris <foo at bar.com> wrote:

>"Functions marked as final may not be overridden in a derived class, 
>unless they are also private."
>
>Just how much does "final" get paid for this? Onto the given example:

...

>2) Seems to me the usage of "final" here is entirely misleading, and 
>opens up a lurking hole for some poor sod to break their ankle in.

Having been in C++ mode for a bit, I'm probably misunderstanding the
issue, but for what it's worth...

Aren't private members excluded from the virtual table? Early bound,
in other words?

If so, one way to view it is that private methods cannot be overridden
and are therefore inherently final, so it does no particular harm to
actually say that they are final. Either requiring 'final' or banning
it might help code consistency and readability, but it seems like a
minor issue.

How can I say that a private method can't be overridden? Well, if
there is no late binding, a new method with the same signature isn't
really an override.

The private method doesn't really exist in any derived classes
interface, internal or external. The only reason that derived classes
are aware at all is to improve the compiler error messages. So any
method added to a derived class with the same signature is just a
completely new and independent method - not an override. It's really
no different to having a method with the same signature in an
unrelated class.

Potentially confusing enough to get a note in the documentation,
maybe, but do we really want to ban derived classes from using certain
method signatures just because they were used for private methods in
the base class? That sounds like a violation of encapsulation to me.
The derived classes shouldn't need to know about the private members
of the base class at all, even for the purposes of avoiding name
clashes. 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.

Ah! you say, but we're talking about code in the same module. But then
we get different rules for whether a derived class can define certain
method signatures based on which module it happens to be in. Sure, you
can rename the private methods in the base class to avoid a clash if
you need to, but without reliable refactoring tools to catch all the
calls, that can be potentially error-prone.

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