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: on...@yahoo.com
