The Non-Virtual Interface idiom in D

[Bill Baxter]

On Tue, Sep 29, 2009 at 8:46 AM, Don <nospam at nospam.com> wrote:
> 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).

They might in practice, but the current preaching I hear is to
generally to make the slimmest and least virtual interface you can get
away with.  Of course nobody would need to preach about such
methodology if there weren't some contrary trend commonly seen out in
the wild.

--bb