www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - opDispatch doesn't play nice with inheritance

reply Carl Sturtivant <sturtivant gmail.com> writes:
//Consider this:
import std.stdio;

void main() {
     X obj = new Y;
     writeln( obj._f() );
}

class Proxy {
     X x;
     this(X x) { this.x = x; }
     string _f() { return "Proxy._f called"; }
}

class X {
     auto opDispatch(string f, Args...)(Args args) {
         Proxy p = new Proxy(this);
         return mixin("p."~f~"(args)");
     }
}

class Y : X {
     string _f() { return "Y._f called"; }
}
//

Presumably the presence of obj._f()in main causes the compilation 
of a function _f() in the class X, yet the function _f() in Y 
that inherits it merely shadows it; the keyword override cannot 
be used for this function.

opDispatch is special in that it allows for functions to be added 
to a class or struct when undefined overtly but used elsewhere 
but it seems those functions sadly are final.

Can anything useful be done to remedy the situation?
Nov 15 2018
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 15 November 2018 at 17:14:21 UTC, Carl Sturtivant 
wrote:
 opDispatch is special in that it allows for functions to be 
 added to a class or struct when undefined overtly but used 
 elsewhere but it seems those functions sadly are final.
Right, all templates are final, including opDispatch. What I've done in the past is to forward them to a virtual function with runtime arguments instead of compile time arguments. Kinda like: void opDispatch(string name)() { callMethod(name); } /* virtual */ void callMethod(string name) { // do a reflection loop or associate array or switch or whatever to dispatch it here, reimplemented (or at least re-mixed-in) in the child classes to account for their new methods } What exactly do you need to do with it? Maybe you can do an alternative design.
Nov 15 2018
parent Carl Sturtivant <sturtivant gmail.com> writes:
On Thursday, 15 November 2018 at 18:04:42 UTC, Adam D. Ruppe 
wrote:
 Right, all templates are final, including opDispatch.

 What I've done in the past is to forward them to a virtual 
 function with runtime arguments instead of compile time 
 arguments.

 Kinda like:

 void opDispatch(string name)() {
      callMethod(name);
 }

 /* virtual */ void callMethod(string name) {
      // do a reflection loop or associate array or switch or 
 whatever to dispatch it here, reimplemented (or at least 
 re-mixed-in) in the child classes to account for their new 
 methods
 }



 What exactly do you need to do with it? Maybe you can do an 
 alternative design.
Well, I found an alternative design not using opDispatch, not fundamentally dissimilar to what you suggested above, thanks for that, and it's not too uneconomical in its textual organization. I was hoping to avoid doing any of my own dispatching when inheritance would do it for me.
Nov 15 2018
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 11/15/2018 09:14 AM, Carl Sturtivant wrote:

 opDispatch is special in that it allows for functions to be added to a
 class or struct when undefined overtly but used elsewhere but it seems
 those functions sadly are final.

 Can anything useful be done to remedy the situation?
For the compiler to be able to make all opDispatch instantiations virtual, it would have to first see all calls that generate opDispatch instantiations. (Impossible in the presence of separate compilation.) Only then the compiler would know how large the vtbl of the base class should be and what member functions of the derived class are overrides of those virtual functions. I think it would be confusing as well; a function suddenly becomes virtual just because someone else made a call on the base class interface. Ali
Nov 15 2018
parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Thursday, 15 November 2018 at 19:01:45 UTC, Ali Çehreli wrote:
 On 11/15/2018 09:14 AM, Carl Sturtivant wrote:

 opDispatch is special in that it allows for functions to be
added to a
 class or struct when undefined overtly but used elsewhere but
it seems
 those functions sadly are final.

 Can anything useful be done to remedy the situation?
For the compiler to be able to make all opDispatch instantiations virtual, it would have to first see all calls that generate opDispatch instantiations. (Impossible in the presence of separate compilation.) Only then the compiler would know how large the vtbl of the base class should be and what member functions of the derived class are overrides of those virtual functions.
I suppose it's such administrative difficulties that led to D defining anything that might conceivably be overridden to be virtual, whether or not actually overridden.
Nov 17 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, November 17, 2018 11:09:51 PM MST Carl Sturtivant via 
Digitalmars-d-learn wrote:
 On Thursday, 15 November 2018 at 19:01:45 UTC, Ali «ehreli wrote:
 On 11/15/2018 09:14 AM, Carl Sturtivant wrote:
 opDispatch is special in that it allows for functions to be
added to a
 class or struct when undefined overtly but used elsewhere but
it seems
 those functions sadly are final.

 Can anything useful be done to remedy the situation?
For the compiler to be able to make all opDispatch instantiations virtual, it would have to first see all calls that generate opDispatch instantiations. (Impossible in the presence of separate compilation.) Only then the compiler would know how large the vtbl of the base class should be and what member functions of the derived class are overrides of those virtual functions.
I suppose it's such administrative difficulties that led to D defining anything that might conceivably be overridden to be virtual, whether or not actually overridden.
The issue with templated functions is that you don't have the full list of instantiations when the base class is compiled, whereas as I understand it, the issue with virtual-by-default is more of an issue of choosing code correctness by default over efficiency by default. You can get some fun, subtle bugs in C++ when you call non-virtual functions in circumstances where they were overridden and used as if they were virtual. So, by making all public and protected class member functions virtual by default and not allowing non-virtual functions to be overridden, it prevents a whole class of bugs. It _does_ have some performance downsides in that it easily leads to functions being virtual when they don't need to be, which can be gotten around with some extra effort, but it's effectively favoring correctness by default over efficiency. And for a lot of programs, it's a great tradeoff, especially when the whole point of classes in D is to use inheritance and polymorphism, and the cases where you don't need it, you use a struct. For the rest, final can be used to devirtualize a function as long as it's not overriding a function. To avoid bugs in the same way that we currently do without having virtual be the default, we probably would have had to make it illegal to override any class functions unless they were explicitly virtual, which would have created a different set of problems. And whether that would be better or worse is a matter of debate. In the end, it's a matter of tradeoffs, and which is better is likely to depend on how your applications benefit from and use the feature. If most of your class functions are used polymorphically, then having to mark them as virtual or having to put virtual: at the top of your class would get really annoying, whereas if you typically have only a few virtual functions and then lots of non-virtual property functions (like the AAA guys apparently like to do), then having to mark things with final to devirtualize them is very annoying. There's no pleasing everyone. Either way, allowing overriding non-virtual functions like C++ does would just be begging for bugs. - Jonathan M Davis
Nov 18 2018