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

Steven Schveighoffer schveiguy at yahoo.com
Fri May 27 05:08:37 PDT 2011


On Fri, 27 May 2011 07:42:17 -0400, Matthew Ong <ongbp at yahoo.com> wrote:

> On 5/27/2011 7:08 PM, Steven Schveighoffer wrote:
>>
>> I don't think it will work that well. Consider how function hijacking
>> happens. For instance, the parent class author may not even know his
>> code is being overridden, and he may simply not mark his base function
>> as nooverload. Let's say that the child is inheriting all the parent's
>> methods because he wanted a different method (an already existing one),
>> and the author of the parent class adds methodA (without the nooverload
>> attribute) after the child is already written. That's an unintentional
>> hijack. The problem is the child is relying on the parent to cooperate
>> in preventing hijacking, instead of controlling whether its functions
>> can be hijacked or not.
>>
>> In the current solution, the system warns me or throws an error if a
>> function becomes hijacked. If this happens, I can examine the code and
>> add an alias if needed. It happens rarely for me. Do you have cases
>> where you have to "alias all over the place"? Maybe you are not doing
>> something correctly, you shouldn't need this feature all the time.
>>
>> Note that drastic proposals like this are very unlikely to be accepted.
>> Especially for something that has been in use and not really complained
>> about for years. You need to present a very compelling argument,
>> including real examples is helpful. Also, if there's any way to get rid
>> of adding a keyword, you have a much better shot of success. No keywords
>> have been added to the language for a long time.
>>
>> -Steve
>
> Hi Steve,
>
> Please note that the proposal is not to remove the existing function  
> hijacking detection but as an alternative to the existing aliasing.

OK, but I don't see the point then.  Can't you get the functionality you  
desire already?

>
>
>  >Consider how function hijacking happens. For instance, the parent  
>  >class author may not even know his code is being overridden, and he  
>  >may simply not mark his base function as nooverload.
>  From OO stand point, overloading is NOT overriding.
> Please do not mix up the two. Fundamentally different.

Sorry, I used the wrong term, I meant derived or extended.

>  >parent class adds methodA (without the nooverload attribute)
> If that happens, still flag as function hijacking using existing  
> detection. Please note that I did NOT ask for the removal of using
> aliasing on existing source code for inherited overloaded function.

Yes, but you marked the child as inheritall, doesn't this implicitly pull  
in the parent functions as if an alias were entered?  Eseentially, the  
inheritall keyword disables all inheritance hijacking checks.  Or did I  
misunderstand this?

> BTW, default D documentation is Not too friendly for inheritance tree  
> navigation. Unlike in java.

This is definitely a problem, ddoc is very underdeveloped.  There are some  
alternative doc generators out there, I think Tango uses dil, which is a  
d-based compiler that does not yet generate code, but will generate docs  
(and much better docs at that).

But let's not add features to cover up another problem that should be  
fixed in its own right.

> However, new keywords can be added to the compiler. So that future code
> can be written without spending many brain cycle on looking up such  
> alias. Let the compiler do the hard work of AST searching rather than
> a manual process. We have quad core now a days, even in asia.

The issue is not whether the compiler can search the AST, the issue is  
whether it makes functions easier to be hijacked.

> Have you systemetic go over the proposal I posted and gave your counter  
> arguement? How about the fact that currently there are such aliasing all  
> over the child class. From what I understand D inheritance is Not  
> automatic, if I am wrong do let me know.
>
> Do you have cases where you have to "alias all over the place"?
> news://news.digitalmars.com:119/iri4am$2dl3$1@digitalmars.com
>
> http://hg.dsource.org/projects/dwt2/file/d00e8db0a568/base/src/java/io/ByteArrayInputStream.d

Only read is required to be aliased, due to the base function read(byte[]  
b).  All the others are unnecessary.

I may see why you see so many cases -- dwt was likely ran through a java  
to d converter, and such converters often add unnecessary lines, because  
it is easier to do that than to examine each individual case.

This further weakens your proposal in two ways:

   1. The compiler does not need to foster to one small specific porting  
tool which does not generate optimal code.
   2. Your argument is based on having to manually search for functions to  
alias, yet this tool clearly did all the aliasing for you.

Essentially, your proposal makes it easier to make D inheritance rules  
more like Java ones, and I don't think we need such a feature.  It's  
already possible to do this via alias, and D's stance is specifically  
*against* Java-style inheritance.

>  >instead of controlling whether its functions can be hijacked or not.
> Why NOT? If a problem can be prevented easily as an modifier keyword.
> Hijacking is not a feature, it is a problem correct???

Anti-hijacking is a feature.  Your proposal removes that when you use  
inheritall.

-Steve


More information about the Digitalmars-d mailing list