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
