private vs protected in Interfaces

[Andrei Alexandrescu]

On 08/15/2010 04:01 AM, Ali Çehreli wrote:
> Jonathan M Davis wrote:
>
>> It would not be good to be unable to do NVI.
>
> I am not saying that it should not be supported; but...
>
> I've used NVI a number of times myself until I was convinced by Kevlin
> Henney that it was "a solution in search of a problem" during one of his
> many excellent presentations at the Silicon Valley ACCU:
>
> http://www.accu-usa.org/Slides/ACriticalViewOfCppPractices.pdf

Interesting. I think Kevlin is an outstanding designer, and I agree with 
him that applying NVI as a convention in languages that have little 
support for it is tenouos.

I disagree with a few points his slides make, and am informing him of 
this discussion to allow him to chime in if he wants.

* Slide 17: Ironically, this slides provides motivation for NVI without 
recognizing it.

* Slide 27: "On close inspection... more mature and proven techniques, 
e.g. the Interceptor pattern". Maturity and proven-worthiness would 
suggest that most everyone should have heard of the Interceptor pattern. 
I knew nothing about the name so I googled for it. Google only finds 
1420 hits for "interceptor pattern" compared to the 76000 hits for "non 
virtual interface" (both quoted to eliminate noise). I'm not saying 
numbers are an ultimate argument, but I find it specious that a mature 
and proven technique has only 1420 hits to speak for it (not to mention 
that the Wikipedia entry is quite underwhelming).

* Slide 28: "NVI lacks either a clear motivation or a clear description 
of benefits" with a scathing sub-bullet. Going to the first google hit 
for "non virtual interface" (wikibooks.org) shows the following intent: 
"To modularize/refactor common before and after code fragments (e.g., 
invariant checking, acquiring/releasing locks) for an entire class 
hierarchy at one location." Not only I find it hard to frame that 
motivator as unclear speculation etc., but I actually find it pretty 
darn good.

* Slide 29: The example given illustrates either an unrealistic mocking 
or a misunderstanding of the pattern: instead of offering _distinct_ 
interfaces to clients and children, it offers the same exact interface, 
just written twice.

The one thing that sucks about NVI is the scant language support for it, 
issue alluded to slide 24. I would have agreed with 4 slides worth of 
detail on that one. In C++ a derived class is free to break NVI in quite 
a number of ways, notably by wrongly overriding (actually hiding) 
functions that aren't virtual. So in C++ NVI is clunky to enact and 
difficult to even maintain. I hope we fixed those in D (implementation 
bugs notwithstanding).


Andrei