On 5/27/11 9:26 AM, Steven Schveighoffer wrote:
On Fri, 27 May 2011 10:10:25 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 5/27/11 1:34 AM, Matthew Ong wrote:
Hi All,
Currently within D, to make use of a parent class method you have to do:
class Parent{
void methodA(int x){...}
}
class Child : Parent{
// I understand that it has to do with preventing accidental hijacking
alias Parent.methodA methodA;
void methodA(long x){...}
}
void main(string[]){
Child obj=new Child();
obj.methodA(1); // expecting to call Child.methodA but calling
Parent.methodA;
}
and also from this URL.
http://www.digitalmars.com/d/2.0/function.html
If, through implicit conversions to the base class, those other
functions do get called, an std.HiddenFuncError exception is raised.
I can't believe this has fallen off the radar.
There should be no std.HiddenFuncError. Such errors must ALL be
detected during compilation.
You have three options:
1. keep the base implementation in place. If someone casts to the base
class, and calls the hidden function, it just works.
2. force the user to override *all* overloads of the base, or alias them
in.
3. Throw the hidden function error.
4. Statically disallow overloaded overridable methods when the
parameters of one automatically convert to the parameters of another.
1 is how D used to be. I think Walter has some good case for why it is
undesirable.
2 is just annoying. Either you will just alias the base functions
(resulting in possible hijacking) or you will implement stub functions
that throw an exception. If you want to go this route, I'd rather just
have default aliasing of base functions.
2 is the only way to have a "compile" error. It is impossible to
statically check if a function using a base class is actually using a
derived class that hides the function being called. That is, you can
only statically disallow the compilation of the derived class, not the
hidden function call.
Personally, I think the current implementation (item 3) is the least
annoying.
-Steve
It is completely against the spirit of the language to decide that a
call is resolved to an invalid method during runtime. There is no other
feature remotely related to hiddenfunc.
A couple of years ago, Walter gave a talk on hijacking to NWCPP. It all
went well until HiddenFunc, at which point Walter's assertion that the
way out was by throwing an exception was hotly debated. Several people
suggested alternative, of whom one proposed (4) above. Everybody agreed
it's a good solution, and Walter had the presence of mind and humility
to acknowledge that solution and to promise to look into implementing
it. Unfortunately, that event was forgotten... until now.
Andrei
