visibility vs. accessibility of protected symbols

[Jonathan M Davis]

On Tuesday, February 14, 2012 03:45:54 Timon Gehr wrote:
> On 02/14/2012 03:05 AM, Jonathan M Davis 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
> 
> That article uses C++. It is not really a fair comparison, because in D
> there is no way to explicitly declare a method "private virtual", and
> D's private is different from C++'s private, and C++ has a different
> sub-typing and inheritance model. I think there are different design
> trade-offs at play.
> 
> But I can make better sense of your point of view now: When I was
> talking about virtual I meant just a function that has an entry in a
> vtbl and is invoked virtually, while you probably had C++'s semantics in
> mind.

I'm not aware of _any_ difference between virtual functions in C++ and D except 
for the fact that all public and protected member functions are always virtual 
in D (unless the compiler is able to determine that it can make them non-
virtual), and currently private and protected functions are never virtual. 
What differences are you referring to?

- Jonathan M Davis