Opt-out polymorphism?

[Steven Wawryk]

Generalizing the original question to *all* member functions, it can be 
desirable to to have non-polymorphic inheritance, at least not *runtime* 
polymorphic.  I get the impression that it wouldn't be used much by most 
people who post on these newsgroups, but there are application areas it 
can be very useful.

For example, in tightly embedded applications it can be important to 
minimize code-bloat in the use of templates in C++, so presumably also 
applicable to parametized classes/structs in D.  In C++ the idiom I'm 
refering to has the template inherit the 
template-parameter-type-independent (common) code from a non-template 
base.  An example plucked out of the air could be a linked list, the 
link logic with no payload could be encapsulated in a non-template base 
and the payload logic added in a template class that derives from it.  I 
expect that it would also be useful in D if embedded application 
programming were an area that D were serious about catering for.

The criterion that determines whether it needs to be runtime polymorphic 
or not is whether the resulting object is intended to be used through 
its base class (polymorphic) interface or its derived class 
(non-polymorphic) interface.

Aside: this distinction is the reason for Herb Sutter's C++ guideline 
"Always make base class destructors virtual and public or nonvirtual and 
protected" from his book "More Exceptional C++".

Steve


On 14/02/11 11:59, Jonathan M Davis wrote:
> On Sunday 13 February 2011 13:34:04 Sean Eskapp wrote:
>> Is there a way to specify that a function is nonvirtual, but can still be
>> "overriden" in base classes? e.g.
>>
>> class A
>> {
>>      void foo()
>>      {
>>          writeln("A");
>>      }
>> }
>>
>> class B : A
>> {
>>      void foo()
>>      {
>>          writeln("B");
>>      }
>> }
>>
>> void main()
>> {
>>      (new A).foo();
>>      (new B).foo();
>> }
>>
>> Should output:
>> A
>> B
>>
>> Is there a way to do this?
>
> No. It's potentially error-prone to do that, and allowing the programmer to
> specificy that sort of thing complicates things. C# allows you to choose whether
> a function is derived or not in a fairly clear manner, and C++ allows you to do
> it in a somwhat poor manner, but in D, the compiler makes all of the decisions
> about whether a function is virtual or not. That definitely simplifies things, and
> since in virtually all cases, you want virtual functions, it's not generally an
> issue.
>
> The only ways that you're likely to be able to make a function non-virtual in a
> class are by making it private (which may or may not continue to make functions
> non-virtual, since that contradicts TDPL) and if you make a function final. But D
> takes the tact of either it's overridable and virtual, or it's non-overridable
> and non-virtual. So, you can't do what you're trying to do.
>
> And honestly, in most cases, I think that what you're trying to do is just plain
> begging for bugs. It is kind of cool that C# found a relatively clean way to
> deal with it, but I honestly don't know what it's useful for. I'd be worried
> about a program which overrode non-virtual functions. It's highly likely to
> cause bugs.
>
>   Jonathan M Davis