Broken?

[monarch_dodra]

On Wednesday, 12 March 2014 at 13:53:28 UTC, Steven Schveighoffer 
wrote:
> Nonsense. If I'm writing a function, I can call it. There is no 
> way to prevent it.

Yes, you are right. You can always call the function directly if 
you so wish, since you *are* defining it.

But the idea is that it should just be a "piece of 
implementation" that should only be used in a controlled 
environment, as defined by the base class.

> OK, so your idea is that I can't call my copy of _foo, which if 
> that's how it works, is dumb in my opinion. But if that's the 
> case, I'm in control of its implementation, I can just forward 
> to another function that I can call.

Absolutely. And in NVI, arguably, that's a good idea.

By doing this, you are basically creating a second level NVI for 
a potential third level implementation.

*if* your derived class made a direct call to the virtual 
(protected) function, then you'd be voiding the base classes' 
guarantees for any other derived class.

> The idea is fine, but protected serves this purpose just as 
> well.

The basic idea of NVI is encapsulation of behavior. The derived 
class, while they are the ones defining the implementation, are 
considered no different from any other client, and are not given 
call rights.

If you make the functions protected, then you are granting them 
access to implementation internals, which means weaker 
encapsulation. For a 1-level hierarchy, it doesn't make much 
difference, but the deeper you go, and the less robust the design 
gets.