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

[Andrei Alexandrescu (See Website For Email)]

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).


Andrei