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.

-----------------------------------------------------------------------
That is to prevent silently changing the program's behavior. b.foo(1) could happily be a call to B.foo(long) today. Imagine one of the base classes changed and now there is A.foo(int). Then our b.foo(1) would silently start calling that new function. That would cause a tough bug.
Ali  // a Better explanation than the document for the current syntax.
------------------------------------------------------------------------

However, there is a foreseeable problem coming when a program grow.
How about when the inheritance tree becomes deeper than 4? And more and more overloaded functions are in different classes? That does not meant the calling class/method has a sense if it is calling from Child or Parent. Because, those 2 classes source code might not be available for coder. How does the coder knows about that?

Does it mean we have to do more alias at child class at the bottom? Harder to issues solve in the child class at the bottom of the tree.

It seem to me that the entire purpose is just to protect auto promotion matching method signature in the base to avoid function hijacking.

How about doing this another way? Just a suggestion if you like to avoid parent function from accidental hijack but still needs to be public. New keywords are needed: nooverload and inheritall

class Parent{
    nooverload void methodA(int x){...} // entirely deny this name to be overloaded.
}

// this would have avoided the aliasing all over child class and still allow child class to see any >public< method of the parent.

class Child: inheritall Parent{ // auto inheriting all parent methods except private ones. As per usual also for package/protected...
    void methodA(long x){...} // compilation error. because nooverload is used at Parent
    void methodA(string x){...} // compilation error. because nooverload
    ... etc

    void methodB(){
        methodA(123); // No error now, and the entire hijacking is avoided.
    }
}

void main(string[] args){
   Child obj=new Child();
   obj.methodB(); // no problem
   obj.methodA(123); // no accidental hijacking...Always use parent class.
}

Reverse sequence as Ali has shown can also be avoided because if someone does that by adding 'new' methodA in parent where child already has methodA overloaded already without knowledge. Show up in compilation exception for such cases with -w flag on.

How about that? Possible solution?

-- 
Matthew Ong
email: ongbp@yahoo.com

On 2011-05-27 08:34, 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.
>
> -----------------------------------------------------------------------
> That is to prevent silently changing the program's behavior. b.foo(1)
> could happily be a call to B.foo(long) today. Imagine one of the base
> classes changed and now there is A.foo(int). Then our b.foo(1) would
> silently start calling that new function. That would cause a tough bug.
> Ali // a Better explanation than the document for the current syntax.
> ------------------------------------------------------------------------
>
> However, there is a foreseeable problem coming when a program grow.
> How about when the inheritance tree becomes deeper than 4? And more and
> more overloaded functions are in different classes? That does not meant
> the calling class/method has a sense if it is calling from Child or
> Parent. Because, those 2 classes source code might not be available for
> coder. How does the coder knows about that?
>
> Does it mean we have to do more alias at child class at the bottom?
> Harder to issues solve in the child class at the bottom of the tree.
>
> It seem to me that the entire purpose is just to protect auto promotion
> matching method signature in the base to avoid function hijacking.
>
> How about doing this another way? Just a suggestion if you like to avoid
> parent function from accidental hijack but still needs to be public. New
> keywords are needed: nooverload and inheritall
>
> class Parent{
> nooverload void methodA(int x){...} // entirely deny this name to be
> overloaded.
> }
>
> // this would have avoided the aliasing all over child class and still
> allow child class to see any >public< method of the parent.
>
> class Child: inheritall Parent{ // auto inheriting all parent methods
> except private ones. As per usual also for package/protected...
> void methodA(long x){...} // compilation error. because nooverload is
> used at Parent
> void methodA(string x){...} // compilation error. because nooverload
> ... etc
>
> void methodB(){
> methodA(123); // No error now, and the entire hijacking is avoided.
> }
> }
>
> void main(string[] args){
> Child obj=new Child();
> obj.methodB(); // no problem
> obj.methodA(123); // no accidental hijacking...Always use parent class.
> }
>
> Reverse sequence as Ali has shown can also be avoided because if someone
> does that by adding 'new' methodA in parent where child already has
> methodA overloaded already without knowledge. Show up in compilation
> exception for such cases with -w flag on.
>
> How about that? Possible solution?

How big is this problem in practice, how often do need overload (NOT override) a method in the subclass that exists in the super class?

-- 
/Jacob Carlborg

On 5/27/2011 2:54 PM, Jacob Carlborg wrote:
Hi Jacob,

See some of the source code shown here. I did not code them, but can sense the pattern is not too productive brain cycle invested.
Cycle= trying to locate up the tree of inherited object.

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

Not to promote deep inheritance tree. I actually like to flatten them using interface template and adaptor pattern. Memory usage and object
tree creation clock cycle is smaller.

With overloading and also runtime dynamic method invocation, it makes

http://hg.dsource.org/projects/dwt2/file/d00e8db0a568/base/src/java/io/ByteArrayInputStream.d
> How big is this problem in practice, how often do need overload (NOT
> override) a method in the subclass that exists in the super class?
>
Actually, the argument of reason of using alias is to prevent hijacking as mentioned by others in the URL.

Overloading is actually more frequent than overriding base on data modeling because of polymorphic nature of the OOP concept. I can see no point of doing various naming for a single calculation. Yes, it can be done with various different name, Google Go does NOT have overloading.
ie:

// Please note, the internal logics of such methods may or may be the same, because of dependent of business logic. Hence, functional template might not be needed.

class RiskAccessment{
    double calculate(NormalAccount acc, double intrest){...}
    double calculate(CurrentAccount acc, double intrest){...}
    double calculate(FixedDeposit acc, double intrest){...}
    double calculate(FixedIncome acc, double intrest){...}
    double calculate(Equity acc, double intrest){...}
    double calculate(FixedAssets acc, double intrest){...}
}
and many other such patterns.

Overriding is for entirely different thing. Hence, I suggested the 2 new keywords solutions.

-- 
Matthew Ong
email: ongbp@yahoo.com

On Fri, 27 May 2011 02:34:34 -0400, Matthew Ong <ongbp@yahoo.com> 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.
>
> -----------------------------------------------------------------------
> That is to prevent silently changing the program's behavior. b.foo(1) could happily be a call to B.foo(long) today. Imagine one of the base classes changed and now there is A.foo(int). Then our b.foo(1) would silently start calling that new function. That would cause a tough bug.
> Ali  // a Better explanation than the document for the current syntax.
> ------------------------------------------------------------------------
>
> However, there is a foreseeable problem coming when a program grow.
> How about when the inheritance tree becomes deeper than 4? And more and more overloaded functions are in different classes? That does not meant the calling class/method has a sense if it is calling from Child or Parent. Because, those 2 classes source code might not be available for coder. How does the coder knows about that?
>
> Does it mean we have to do more alias at child class at the bottom? Harder to issues solve in the child class at the bottom of the tree.
>
> It seem to me that the entire purpose is just to protect auto promotion matching method signature in the base to avoid function hijacking.
>
> How about doing this another way? Just a suggestion if you like to avoid parent function from accidental hijack but still needs to be public. New keywords are needed: nooverload and inheritall
>
> class Parent{
>      nooverload void methodA(int x){...} // entirely deny this name to be overloaded.
> }
>
> // this would have avoided the aliasing all over child class and still allow child class to see any >public< method of the parent.
>
> class Child: inheritall Parent{ // auto inheriting all parent methods except private ones. As per usual also for package/protected...
>      void methodA(long x){...} // compilation error. because nooverload is used at Parent
>      void methodA(string x){...} // compilation error. because nooverload
>      ... etc
>
>      void methodB(){
>          methodA(123); // No error now, and the entire hijacking is avoided.
>      }
> }
>
> void main(string[] args){
>     Child obj=new Child();
>     obj.methodB(); // no problem
>     obj.methodA(123); // no accidental hijacking...Always use parent class.
> }
>
> Reverse sequence as Ali has shown can also be avoided because if someone does that by adding 'new' methodA in parent where child already has methodA overloaded already without knowledge. Show up in compilation exception for such cases with -w flag on.
>
> How about that? Possible solution?
>

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

On 5/27/2011 7:08 PM, Steven Schveighoffer wrote:
> On Fri, 27 May 2011 02:34:34 -0400, Matthew Ong <ongbp@yahoo.com> 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.
>>
>> -----------------------------------------------------------------------
>> That is to prevent silently changing the program's behavior. b.foo(1)
>> could happily be a call to B.foo(long) today. Imagine one of the base
>> classes changed and now there is A.foo(int). Then our b.foo(1) would
>> silently start calling that new function. That would cause a tough bug.
>> Ali // a Better explanation than the document for the current syntax.
>> ------------------------------------------------------------------------
>>
>> However, there is a foreseeable problem coming when a program grow.
>> How about when the inheritance tree becomes deeper than 4? And more
>> and more overloaded functions are in different classes? That does not
>> meant the calling class/method has a sense if it is calling from Child
>> or Parent. Because, those 2 classes source code might not be available
>> for coder. How does the coder knows about that?
>>
>> Does it mean we have to do more alias at child class at the bottom?
>> Harder to issues solve in the child class at the bottom of the tree.
>>
>> It seem to me that the entire purpose is just to protect auto
>> promotion matching method signature in the base to avoid function
>> hijacking.
>>
>> How about doing this another way? Just a suggestion if you like to
>> avoid parent function from accidental hijack but still needs to be
>> public. New keywords are needed: nooverload and inheritall
>>
>> class Parent{
>> nooverload void methodA(int x){...} // entirely deny this name to be
>> overloaded.
>> }
>>
>> // this would have avoided the aliasing all over child class and still
>> allow child class to see any >public< method of the parent.
>>
>> class Child: inheritall Parent{ // auto inheriting all parent methods
>> except private ones. As per usual also for package/protected...
>> void methodA(long x){...} // compilation error. because nooverload is
>> used at Parent
>> void methodA(string x){...} // compilation error. because nooverload
>> ... etc
>>
>> void methodB(){
>> methodA(123); // No error now, and the entire hijacking is avoided.
>> }
>> }
>>
>> void main(string[] args){
>> Child obj=new Child();
>> obj.methodB(); // no problem
>> obj.methodA(123); // no accidental hijacking...Always use parent class.
>> }
>>
>> Reverse sequence as Ali has shown can also be avoided because if
>> someone does that by adding 'new' methodA in parent where child
>> already has methodA overloaded already without knowledge. Show up in
>> compilation exception for such cases with -w flag on.
>>
>> How about that? Possible solution?
>>
>
> 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.


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

http://users.soe.ucsc.edu/~charlie/book/notes/chap7/sld012.htm

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

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

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.

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 


>Maybe you are not doing something correctly, you shouldn't need this feature all the time.
Not me, others that has coded the dwt and I suspect other code in dsource where they tries to mimic Java Library and perhaps C# also.


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

>No keywords have been added to the language for a long time.
Perhaps there is no-one that seen different from angle?

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.

That is a tasks burdensome enough for most person.

-- 
Matthew Ong
email: ongbp@yahoo.com

On Fri, 27 May 2011 07:42:17 -0400, Matthew Ong <ongbp@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

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

On Fri, 27 May 2011 08:36:08 -0400, Matthew Ong <ongbp@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

On 2011-05-27 13:42, Matthew Ong wrote:
> On 5/27/2011 7:08 PM, Steven Schveighoffer wrote:
>
> 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
>
>
>  >Maybe you are not doing something correctly, you shouldn't need this
> feature all the time.
> Not me, others that has coded the dwt and I suspect other code in
> dsource where they tries to mimic Java Library and perhaps C# also.

DWT is a direct port of the Java library SWT and it tries to stay as close to the original code base as possible to easy merges of future release of SWT.

When coding my own projects (projects I've written from scratch and not ported from other languages) it's a feature I rarely use, don't know if I ever have used it.

-- 
/Jacob Carlborg

On 2011-05-27 14:08, Steven Schveighoffer wrote:
> On Fri, 27 May 2011 07:42:17 -0400, Matthew Ong <ongbp@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.

DWT is manually ported from Java. A automatic port was tried and it didn't workout that well, too much of the Java standard library needed to be reimplemented in D. The port tries to stay as close to the original code base as possible to ease merging future versions of SWT and to minimize porting bugs.

-- 
/Jacob Carlborg