www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implement disable methods as always-throw methods?

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I'm curious about this case:

import std.stdio;

abstract class Widget
{
    void add(Widget w)    { writeln("add");    }
    void remove(Widget w) { writeln("remove"); }
}

class Leaf : Widget
{
     disable override void add(Widget Widget)    { writeln("disabled"); }
     disable override void remove(Widget Widget) { writeln("disabled"); }
}

void main()
{
    Widget leaf = new Leaf;
    leaf.add(new Leaf);
}

The compiler can't catch this since 'leaf' has the static type Widget,
so Leaf's virtual function will still get called. Of course you could
cast leaf to Leaf, but that's beside the point that a disabled method
ultimately gets called.

I was thinking, would it be a good idea for the compiler to implement
disabled methods as always-throw methods? If it can't catch them being
called at compile time then at least you would get a runtime error if
they were to throw.

Thoughts?
Oct 02 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/02/2011 07:41 PM, Andrej Mitrovic wrote:

 I'm curious about this case:

 import std.stdio;

 abstract class Widget
 {
      void add(Widget w)    { writeln("add");    }
      void remove(Widget w) { writeln("remove"); }
 }

 class Leaf : Widget
 {
       disable override void add(Widget Widget)    { writeln("disabled"); }
       disable override void remove(Widget Widget) { writeln("disabled"); }
 }

 void main()
 {
      Widget leaf = new Leaf;
      leaf.add(new Leaf);
 }

 The compiler can't catch this since 'leaf' has the static type Widget,
 so Leaf's virtual function will still get called. Of course you could
 cast leaf to Leaf, but that's beside the point that a disabled method
 ultimately gets called.

 I was thinking, would it be a good idea for the compiler to implement
 disabled methods as always-throw methods? If it can't catch them being
 called at compile time then at least you would get a runtime error if
 they were to throw.

 Thoughts?



Imho disabling overriden member functions is unsound and should be 
disallowed entirely.
Oct 02 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/2/2011 10:59 AM, Timon Gehr wrote:

 Imho disabling overriden member functions is unsound and should be disallowed
 entirely.



I agree, as disabling an override doesn't make any sense. If the user wants an 
exception thrown if the overriding function is called, he can add a 'throw' in 
it himself.

How about filing a bugzilla for this?
Oct 02 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/02/2011 10:05 PM, Walter Bright wrote:

 On 10/2/2011 10:59 AM, Timon Gehr wrote:

 Imho disabling overriden member functions is unsound and should be
 disallowed
 entirely.



 I agree, as disabling an override doesn't make any sense. If the user
 wants an exception thrown if the overriding function is called, he can
 add a 'throw' in it himself.

 How about filing a bugzilla for this?



Done: http://d.puremagic.com/issues/show_bug.cgi?id=6760
Oct 02 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/2/2011 1:34 PM, Timon Gehr wrote:

 Done: http://d.puremagic.com/issues/show_bug.cgi?id=6760



Tanks!
Oct 02 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, October 02, 2011 19:59:01 Timon Gehr wrote:

 Imho disabling overriden member functions is unsound and should be
 disallowed entirely.



Agreed. It goes against the basic principles of OO design. A derived class 
_is_ an instance of its base class, and it should be possible to treat it as 
its base class. Disabling overridden functions goes completely against that 
and therefore seems like a _really_ bad design.

- Jonathan M Davis
Oct 02 2011