[Issue 3581] "private" attribute breaks "override"

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3581



--- Comment #7 from Jonathan M Davis <jmdavisProg at gmx.com> 2011-03-01 14:48:17 PST ---
They can't be kept apart as long as you can't specify whether a function is
virtual or not. In C++, a member function is not virtual unless you mark it as
virtual (or a base class has a function with the same name which is marked
virtual). So, you can get into problems where you override functions but don't
make them virtual, so which version of a function you call depends on what type
of pointer you're using (yuck). D just makes all member functions virtual
except those which it knows don't have to be. It currently treats private as
non-virtual (and therefore non-overridable since all overridable functions must
be virtual in D as just mentioned), presumably with the idea that there's no
point in overriding a private function (forgetting NVI).

C++ does allow the overiding of private functions. The typical case where you
do that would be NVI, where you make a public function which is non-virtual and
a private one which is virtual and overridden in derived classes. That way, the
private, virtual function can only be called in the base class, and you can
enforce that certain things happen before or after the call to the private
function, because the only place that it ever gets called is within the public,
non-virtual function in the base class.

It's a nice idiom, but it can be pretty much done the same way using protected
instead of private (particularly since there are ways to get around the
uncallability, IIRC - probably by just casting the this pointer to the base
class type). It also doesn't cause a penalty in C++, because your private
functions are usually non-virtual and completely inlinable. In D, however,
because you _can't_ specify a function as non-virtual, if you made private
functions overridable, they must be virtual, and all of a sudden, the compiler
can't inline _any_ private functions unless they're final. It doesn't know what
all of the derived classes look like and whether they override a particular
function, so it must assume that they'll be overriden and would have to make
the virtual.

So, if we make it possible to override private functions in D, it would pretty
much have to become common practice to mark all private functions as final
unless you were specifically using NVI, otherwise you're going to take a
definite performance hit in a lot of cases. On the other hand, we could leave
private as unoverridabel and just say that NVI has to use protected instead of
private. It works just as well and doesn't require that you mark almost every
private function that you ever write as final.

You _can't_ separate access level from virtuality in D, because non-virtuality
is done as an optimization rather than a function being virtual on non-virtual
being at the programmer's request.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------