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

[Steven Schveighoffer]

On Fri, 27 May 2011 08:36:08 -0400, Matthew Ong <ongbp at yahoo.com> wrote:

> On 5/27/2011 8:08 PM, Steven Schveighoffer wrote:
>> Sorry, I used the wrong term, I meant derived or extended.
> Explain please. You lost me. If I am not wrong, final is used to prevent  
> overriding. Is that what you are talking about?

No, I mean the author of Parent may not know of the existance of child,  
and its implementation of methodA.

Let me walk you through a scenario.

Author 1 implements Parent:

class Parent
{
    void methodB(int i) {...}
}

Author 2 wants to inherit from Parent, but he also wants to overload  
methodB, so he writes:

class Child : Parent
{
    void methodB(string s) {...}
    void methodA(long l) {...}
}

To allow one to call the parent's methodB, he uses your new keyword:

class Child : inheritall Parent
...

Now, sometime in the future, Author 1, without knowing about Author 2's  
derivation of his work, decides to add methodA which does something  
completely different from Child's implementation:

class Parent
{
    void methodB(int i) {...}
    void methodA(int i) {...}
}

Because Child is marked as inheritall, it compiles without complaint, and  
a call to childinstance.methodA(1) now calls the new Parent's methodA,  
when previously it called Child's methodA.

This is a form of hijacking.  Compare this to if you simply aliased  
methodB:

class Child : Parent
{
    alias Parent.methodB methodB;
    ....
}

Now, the hijacking introduced with methodA is properly disallowed, and  
calling methodA on the base throws a hidden function error.

>> 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?
>
> inheritall only to that single class and not from child to child and so  
> on.
> Because of the nooverload keyword. There is a better way to further  
> enhance that anti-hijacking proctection. It is a manually controlled  
> approaches by developer of the child class.

Isn't nooverload supposed to be on the Parent class?  How would Author 1  
know about Child and know he should put nooverload on methodA when he adds  
it?

>> 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).
> Do both improvement. Please also support my post on:
> Example within documentations of D seriously need some improvement.
> Please place in the issue you see there compare to others languages  
> already has.

The poor navigability of DDoc generated documentation is not a new  
problem.  It's been bad for years.  It receives little attention because  
there are few people working on the compiler, and their time is spent  
improving the code generating features.  I suspect someone else will have  
to step up in order to get ddoc to generate better docs.  IMO the largest  
problem is that dmd is written in C++, and avoiding C++ is one of the main  
reasons many people are here ;)

>> But let's not add features to cover up another problem that should be
>> fixed in its own right.
> NO. It is not a feature to cover up that problem. It prevents the same  
> issue with less
> manual work.

I'm saying the poor navigability of DDoc documentation is not a  
justification for your proposal.  It might be less manual work, but I  
would argue the manual work is minuscule to begin with.

>> The issue is not whether the compiler can search the AST, the issue is
>> whether it makes functions easier to be hijacked.
> I believe the 2 feature does not make it easier to be hijacked. See  
> above. Compiler can search the AST is key.
>
> Most source code development process needs to look at at least 7  
> different dimensions. Inheritance down the tree, up the tree, interfaces  
> and its implementation, changes over time, testing, cpu cycle, memory  
> creation cycle. That is just single threaded model.

It seems too easy to remove hijacking protection using inheritall.  I  
don't think the nooverload keyword is necessary if inheritall doesn't  
exist, and it seems like something that would be rarely used.  I just  
don't see enough simplification or improvements to justify allowing an  
easy off-switch for hijack protection.

You should know, the very first post I made on this newsgroup (almost 4  
years ago) was to complain about not overloading against base functions,  
and it lead to improved error detection (the hidden func exception), and  
the hijacking article being written.

I think at this point, you have a 0% chance of getting Walter to change  
it.  I don't want to discourage people from coming up with new and  
interesting ideas, but this one is not new.

>> 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.
> It does not seem to be because the dwt library has many different  
> authors.

I'm not saying the entire code based is simply the output of a java  
converter, I'm saying the *aliases* are the result of the converter.  I  
don't see why any person would waste the time to alias in all the base  
class' functions they are fully overriding, why wouldn't they just do the  
ones that are necessary?

Looking again at the code, there is more evidence in the first line:

/* language convertion www.dsource.org/project/tioport */

Note the url is incorrect, it should be:

http://www.dsource.org/projects/tioport

"The TioPort Project does Java to D conversion of whole libraries and  
applications."

>> 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.
> I am referring to manually written and naturally grown business library.
> I do agrees that a language is not design based on how a generated tool  
> create its code.

A fully manually written code base would not contain so many aliases.

>> 2. Your argument is based on having to manually search for functions to
>> alias, yet this tool clearly did all the aliasing for you.
> Yes. If and ONLY if you are doing auto java to D conversion.
> How about when the hand coded library grow?

Then adding the occasional alias is good enough.

-Steve