Module-level accessibility

[Jonathan M Davis]

On Monday, October 04, 2010 13:41:38 Steven Schveighoffer wrote:
> To me, making it private doesn't do anything over protected.  A derived
> class can still call the function in question, because it has the
> implementation.  I don't see what the point is...
> 
> A derived class from the derivative doesn't have access, but it can always
> override it in order to be able to call it (not a good workaround to
> require). 

Except that part of the point is that because the private method is private in 
the base class, it _can't_ be called by derived classes. It can only be 
overridden.

> Not to mention that you can't call the parent class' version,
> so you can't keep that behavior intact.

For some situations, that could be annoying, but there are plenty of cases where 
that wouldn't matter. And I suspect that in many cases when NVI is used, it's 
really only intended that there be one derived class anyway. So, the fact that 
base class versions of the private function can't be called would be irrelevant.

> I see nothing but annoyance for using private virtual functions.

Well, no one says that you have to use it (though obviously, if it's possible, 
and you're working with other people in D, you could be forced  to use it 
because someone else did in their code).

I grant you that NVI is a bit different (when I first learned about it, I was 
shocked to learn that you could override private functions in C++), and I'm not 
about to claim that that's the way the things should be done in general in D, 
but I do think that it's a useful idiom and that making private overridable 
would be useful. And FWIW, TDPL says that it's in the language.

- Jonathan M Davis