www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Opt-out polymorphism?

reply Sean Eskapp <eatingstaples gmail.com> writes:
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?
Feb 13 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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 

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 

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
Feb 13 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 And honestly, in most cases, I think that what you're trying to do is just
plain 

 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.




Bye,
bearophile
Feb 13 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 13 February 2011 17:40:39 bearophile wrote:

 Jonathan M Davis:

 And honestly, in most cases, I think that what you're trying to do is

 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.


 



I never claimed that they were. They cleaned up how overriding works in 
comparison to C++, and they given essentially the same options for overriding
as 
C++ only they definitely do it better.

However, just because it's possible to do something in a particular language 
doesn't mean that it's a good idea to do it. I seriously question that it's 
_ever_ a good idea to have a function which isn't virtual but can be
overridden. 
What reasonable use case does that have. I've never seen it, and I've
definitely 
seen bugs caused by having functions not be virtual and yet still overridden.

definitely improves over C++ in this regard, but the ability to override
without 

language just like C++ did but do it better. The Java and D designers chose to 
make overriding and virtual functions intrinsically linked so that you can't 
override anything that isn't virtual.


allowing non-virtual functions to be overridden is a good idea.

- Jonathan M Davis
Feb 13 2011
prev sibling parent Steven Wawryk <stevenw acres.com.au> writes:
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

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

 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
Feb 13 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 13 Feb 2011 16:34:04 -0500, Sean Eskapp <eatingstaples gmail.com>  
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?


You can make them templates.  Templates are not final, and are not virtual.

e.g.: (untested)


class A
{
     void foo()()
     {
         writeln("A");
     }
}

class B : A
{
     void foo()()
     {
         writeln("B");
     }
}

The huge *huge* drawback is this:

A a = new B;
a.foo(); // outputs "A"

So I don't see a very common use case for this.

-Steve
Feb 14 2011
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 13/02/2011 21:34, Sean Eskapp wrote:

 Is there a way to specify that a function is nonvirtual, but can still be
 "overriden" in base classes? e.g.


Then you're not overriding at all.  You're just declaring a function in the
derived class 
that happens to have the same name.

As such, it seems to me to have little use besides writing confusing code.

Stewart.
Feb 18 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon:


 Then you're not overriding at all.  You're just declaring a function in the
derived class 
 that happens to have the same name.



http://msdn.microsoft.com/en-us/library/51y09td4%28v=vs.71%29.aspx

Bye,
bearophile
Feb 18 2011