Module-level accessibility

[Steven Schveighoffer]

On Mon, 04 Oct 2010 16:14:44 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Monday 04 October 2010 11:26:17 Steven Schveighoffer wrote:
>> What possible use case could private methods being polymorphic allow?
>>
>> A private method can only be called by the class that contains the
>> implementation.  Allowing base classes to call it makes no sense.
>>
>> Make the method protected, it gives the desired effect (including for  
>> the
>> example in the bug report as stated by the original reporter).
>>
>> -Steve
>
> It allows for the non-virtual interface pattern. You declare a final  
> public
> function on the base clase which calls a private virtual one (which is  
> probably
> abstract). Derived classes then override the private virtual method.  
> This allows
> the base class to enforce things about the private virtual method - for  
> instance
> pre and post conditions on the public final method would then always  
> apply to the
> private virtual method. Only the base class can actually call the private
> virtual method, but it still allows for the derived classes to override  
> its
> functionality. It's a useful idiom which D doens't currently support but  
> which
> TDPL specifically discusses and claims that D supports.
>
> Take at look at these for more info:
>
> http://www.gotw.ca/publications/mill18.htm
> http://en.wikibooks.org/wiki/More_C++_Idioms/Non-Virtual_Interface

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).  Not to mention that you can't call the parent class' version,  
so you can't keep that behavior intact.

I see nothing but annoyance for using private virtual functions.

-Steve