When does final mean "maybe, kinda, sorta" ?

[Sean Kelly]

Andrei Alexandrescu (See Website For Email) wrote:
> Sean Kelly wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Sean Kelly wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>> kris wrote:
>>>>> [snip]
>>>>>> In short, it appears the example exhibits some poor practice 
>>>>>> (overriding private methods), is somewhat misleading (one 
>>>>>> certainly *hopes* private cannot be seen beyond module-scope), and 
>>>>>> discusses how to make "final" mean something quite other than final.
>>>>>
>>>>> I agree about the misleading part, but I don't think that 
>>>>> overriding private methods is poor practice. In fact I think it's 
>>>>> rich practice :o). See e.g. 
>>>>> http://www.gotw.ca/publications/mill18.htm.
>>>>
>>>> It's a good design approach, but there's no reason the virtual 
>>>> methods must be private--they could be protected as well.  One could 
>>>> argue that the design is cleaner with the virtual methods private, 
>>>> but since the methods must be overridden by the derived class it's 
>>>> not like any protection attributes are being maintained anyway.  
>>>> Isn't this a current topic of discussion on comp.l.c++.m? :-)
>>>
>>> There is a big difference between private and protected. Private 
>>> means that later-added code cannot call the method, period. It could 
>>> be said that private is "distantly more private" than both protected 
>>> and public because both of the latter allow access by unbounded 
>>> amounts of code.
>>>
>>> So there is indeed something interesting by being required to 
>>> implement something that you're not allowed to call. Something like 
>>> Shirley Temple acting in movies she was too young to be allowed to 
>>> watch :o).
>>
>> But you can call it, or even change its visibility:
>>
>> class Base
>> {
>> private:
>>     virtual void fn() = 0;
>> };
>>
>> class Derived : Base
>> {
>> public:
>>      virtual void fn() {}
>>     void call() { fn(); }
>> };
>>
>> Sure, you can't call it through Base::fn(), but... :-)
> 
> Oh, my hope was that D disallows republicizing private functions :o(. 
> Spectacular failure to provide a great feature...

I think it effectively does, since private functions can not be 
overridden.  The above was C++ (I should have labeled the code).


Sean