On Wednesday, October 06, 2010 05:39:24 Steven Schveighoffer wrote:
> You must not have read my prior post.
Well, I believe that I did read your previous post, but I probably read it too
quickly.
> Given this class:
>
> class A
> {
> abstract private void foo();
> }
>
> You can construct a class B that *can* call its private implementation,
> even if the compiler forbids it from calling foo:
>
> class B : A
> {
> override private void foo() { fooImpl(); }
>
> private void fooImpl() {...}
> }
>
> B can call fooImpl whenever it wants, the base class has no fooImpl
> defined, so the compiler must allow it (unless you want to disallow
> calling all private functions in derived classes?). This is equivalent to
> C++'s behavior where you can call any private function you define.
Hmmm. With mixins and the like it's that much easier to be able to use the same
code which is in the private overridden function. So, no, it doesn't look like
it would be possible to stop the code that is within the private overridden
function from being called, though the function itself couldn't be called.
Conceptually, I very much like the idea of making it possible for derived
classes to override a private function but not call it, but you make a good
argument that it really doesn't buy you much. That being the case, the fact
that
having private functions be non-virtual is a bit of efficiency gain and allows
for
easier inlining, it could be that it's just not worth the trouble. You do get
most of the benefits of NVI with protected. So, I'm not sure that I like it,
but
it is looking like using protected for NVI and leaving private as non-virtual
may be the way to go.
- Jonathan M Davis
