visibility vs. accessibility of protected symbols

[Timon Gehr]

On Friday, 17 February 2012 at 18:35:38 UTC, Jonathan M Davis 
wrote:
> On Friday, February 17, 2012 09:03:32 Steven Schveighoffer 
> wrote:
>> On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis 
>> <jmdavisProg at gmx.com>
>> 
>> wrote:
>> > On Tuesday, February 14, 2012 02:43:29 Timon Gehr wrote:
>> >> On 02/14/2012 02:16 AM, Jonathan M Davis wrote:
>> >> 
>> >> Well, not being able override what cannot be accesses is a 
>> >> quite basic
>> >> requirement of security. Private members cannot be 
>> >> overriden in a
>> >> different module.
>> > 
>> > Have you ever read up on NVI? That's how it's supposed to 
>> > work. The
>> > whole idea
>> > is to have derived classes override functions without being 
>> > able to use
>> > them.
>> > It makes it so that the public function is non-virtual and 
>> > contains
>> > whatever
>> > stuff you want to guarantee is called before or after the 
>> > private
>> > function,
>> > which is then virtual.
>> > 
>> > http://www.gotw.ca/publications/mill18.htm
>> 
>> This does nothing to protect the implementation. You are 
>> deluding
>> yourself if you think you can stop a derived class from 
>> calling it's own
>> implementation! In this case, protected is good enough, and I 
>> like how
>> private is always non-virtual. As Timon says, it's good for 
>> security and
>> module encapsulation.
>
> I know. That's part of why I'm arguing that protected is enough 
> and that private shouldn't be virtual. But pretty much the 
> whole point of doing NVI with private is the theory that you 
> want to guarantee that the derived classes can't call the 
> function. The fact that you can't actually guarantee that just 
> makes the arguments for making private virtual for NVI that 
> much weaker.
>
> But Timon's arguments make it sound like he doesn't understand 
> what NVI is, which was the point of my post.
>
> - Jonathan M Davis

I understand what NVI is. It is just that private methods 
overridable from a different module don't have many merits, 
regardless of how NVI is apparently sometimes implemented in C++. 
The fact that C++ has overridable private methods is quite likely 
just a side-effect of wanting to give some kind of semantics to a 
method declared as both private and virtual. I could argue that 
it sounds like you don't understand what NVI is because you 
assume C++'s private virtual semantics are required for the 
implementation of NVI. ;)

As far as information hiding design goes, we certainly don't want 
to borrow heavily from C++. Its system is unsound.