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

Steven Schveighoffer schveiguy at yahoo.com
Fri May 27 07:26:37 PDT 2011


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.

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


More information about the Digitalmars-d mailing list