Could new keyword help function hijacking and prevented aliasing all over the place??

[Andrei Alexandrescu]

On 5/27/11 9:26 AM, Steven Schveighoffer wrote:
> On Fri, 27 May 2011 10:10:25 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> 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