Module-level accessibility

[Jonathan M Davis]

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