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

[Matthew Ong]

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?

> 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.

>
> 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.

> 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.

> 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.

>
> 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.
If yes, please give some idea on how to do that via a converter.

> 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.

> 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?

> 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.
Yes. I can see some of the problem that might have from reading the 
unintentional function hijacking.  That is why I am proposing the new 
keyword to make thing easier for people to inherit AND ALSO prevent 
highjacking.

>
>> >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


-- 
Matthew Ong
email: ongbp at yahoo.com