On Tuesday, February 14, 2012 21:13:46 Daniel Murphy wrote:
> > private and protected are automatically non-virtual
> 
> You've said that twice now, I think you mean private and package.

Yes. You're right. The excess of p's is confusing me, I guess.

public and protected are automatically virtual.

private and package are automatically non-virtual.

- Jonathan M Davis

On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis <jmdavisProg@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.

-Steve

On 2/17/12 8:03 AM, Steven Schveighoffer wrote:
> On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis
> <jmdavisProg@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.
>
> -Steve

I agree. Walter and I chalked that up to a bug in TDPL that will be superseded by a different implementation.

Andrei

On Friday, February 17, 2012 10:18:32 Andrei Alexandrescu wrote:
> I agree. Walter and I chalked that up to a bug in TDPL that will be superseded by a different implementation.

Good to hear!

- Jonathan M Davis

On Friday, February 17, 2012 09:03:32 Steven Schveighoffer wrote:
> On Mon, 13 Feb 2012 21:05:35 -0500, Jonathan M Davis <jmdavisProg@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

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

On Friday, February 17, 2012 20:02:53 Timon Gehr wrote:
> 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. ;)

It's required if you implement NVI the way that's typical in C++ and the way that is requested in the NVI-related bug report.

You can get close enough to the same effect using protected, so it's arguably not necessary (which is one of the reasons that I'm arguing against making private virtual), but if we're talking about NVI in the traditional sense (which is what the bug report is looking for and TDPL indicates that you can do in its discussion on NVI), it _is_ required.

Fortunately, it looks like Andrei and Walter have agreed that private shouldn't be made virtual, regardless what TDPL says - though what that means for NVI and interfaces, I don't know. Protected may be enough in that case as well.

- Jonathan M Davis