The Non-Virtual Interface idiom in D

[Don]

Bill Baxter wrote:
> On Tue, Sep 29, 2009 at 4:04 AM, Don <nospam at nospam.com> wrote:
>> Andrei Alexandrescu wrote:
>>> In this article:
>>>
>>> http://www.gotw.ca/publications/mill18.htm
>>>
>>> Herb Sutter makes a powerful argument that overridable functions
>>> (customization points) should actually not be the same as the publically
>>> available interface. This view rhymes with the Template Method pattern as
>>> well.
>> Ever since I read that earlier this year, I've wondered about this (from the
>> spec):
>>
>> "All non-static non-private non-template member functions are virtual. This
>> may sound inefficient, but since the D compiler knows all of the class
>> hierarchy when generating code, all functions that are not overridden can be
>> optimized to be non-virtual. 



  the D way of "make it virtual unless we can prove
>> it can be made non-virtual" results, on average, in many more direct
>> function calls."
>>
>> Based on what Herb says, D is actively encouraging bad design...
>>
> 
> I don't think that's even true what the spec says.  How can the
> compiler know "all of the class hierarchy" if you compile modules
> separately? 
Yes, I don't see how it could.

And also, is this statement true?
 >> since C++ programmers tend to "when in doubt, make it virtual"

Do they? (Might be true, but I don't remember ever hearing it anywhere 
else).

I suspect that this paragraph in the spec is a relic from the very early 
days of D. Might be worth going through the spec looking for glib 
statements and hand-waving arguments.





  If you compile the base class module first, it has no way
> of knowing whether or not some class in another module is going to
> come along later and want to override a method.  Could be possible in
> a smart linker, I suppose, but the spec clearly says "compiler".
> Walter just got through telling us how the linker is a very simple
> program, so I doubt OPTLINK at least is capable of such feats.
> 
> --bb