www.digitalmars.com         C & C++   DMDScript  

D - [BUG]: promoting overloaded functions to subclass

reply Lars Ivar Igesund <larsivar igesund.net> writes:
class A {
   void foo() {}
}

class B : A {
   void foo(int i) {}
}

void main() {
   (new B).foo();
}

don't compile with the message
foo.d(10): function foo (int i) does not match argument types ()

It compiles fine if foo (int i) is moved to A.
So, if a method in a subclass has the same name as a method in the
super class, but with a different signature, the method from the
super class is lost. Since they are allowed to live together in the
same class, they should in parent and child classes.

Lars Ivar Igesund
Mar 31 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Lars Ivar Igesund wrote:

 Since they are allowed to live together in the
 same class, they should in parent and child classes.
Not a bug. Overriding a function hides the overridden overloaded functions in the super class. Use an alias to import them. From C:\dmd\html\d\declaration.html: Aliases can also 'import' a set of overloaded functions, that can be overloaded with functions in the current scope: class A { int foo(int a) { return 1; } } class B : A { int foo( int a, uint b ) { return 2; } } class C : B { int foo( int a ) { return 3; } alias B.foo foo; } class D : C { } void test() { D b = new D(); int i; i = b.foo(1, 2u); // calls B.foo i = b.foo(1); // calls C.foo } So long!
Mar 31 2004
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Manfred Nowak wrote:
 Lars Ivar Igesund wrote:
 
 
Since they are allowed to live together in the
same class, they should in parent and child classes.
Not a bug. Overriding a function hides the overridden overloaded functions in the super class. Use an alias to import them. From C:\dmd\html\d\declaration.html: Aliases can also 'import' a set of overloaded functions, that can be overloaded with functions in the current scope: class A { int foo(int a) { return 1; } } class B : A { int foo( int a, uint b ) { return 2; } } class C : B { int foo( int a ) { return 3; } alias B.foo foo; } class D : C { } void test() { D b = new D(); int i; i = b.foo(1, 2u); // calls B.foo i = b.foo(1); // calls C.foo } So long!
I admit that I expected D to function as Java in this regard. My opinion now is that D's spec has a bug. It should NOT be necessary to alias the super class' foo to be able to call it. IMO this defeats much of what makes OOP easy and elegant to use. Walter, please do it the obvious way. Lars Ivar Igesund
Mar 31 2004
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Lars Ivar Igesund wrote:

 Walter, please do it the obvious way.
Have a look at Ben's opinion on that. My opinion is, that the obvious way is already implemented. <btr852$2d1q$1 digitaldaemon.com> == http://www.digitalmars.com/drn-bin/wwwnews?D/21549 So long!
Mar 31 2004
prev sibling next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
It's implemented the C++ way because apparently that's the target audience
for D (rather than Java, for example).

I find the approach totally non-intuitive, and contrary to the notion of
easy-to-learn (surely alias is considered a somewhat 'advanced' topic, if
not downright arcane?).

Personally, I think pandering to C++ history is the wrong approach. Walter
has already sidestepped a lot of the nonsense introduced by Bjarne-The-Toker
... this is one of the last vestiges, and needs some further excising.

- Kris



"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:c4erto$278o$1 digitaldaemon.com...
 Manfred Nowak wrote:
 Lars Ivar Igesund wrote:


Since they are allowed to live together in the
same class, they should in parent and child classes.
Not a bug. Overriding a function hides the overridden overloaded
functions
 in the super class. Use an alias to import them.

 From C:\dmd\html\d\declaration.html:

 Aliases can also 'import' a set of overloaded functions, that can be
 overloaded with functions in the current scope:
 class A {
     int foo(int a) { return 1; }
 }

 class B : A {
     int foo( int a, uint b ) { return 2; }
 }

 class C : B {
     int foo( int a ) { return 3; }
     alias B.foo foo;
 }

 class D : C  {
 }


 void test()
 {
     D b = new D();
     int i;

     i = b.foo(1, 2u); // calls B.foo
     i = b.foo(1); // calls C.foo
 }

 So long!
I admit that I expected D to function as Java in this regard. My opinion now is that D's spec has a bug. It should NOT be necessary to alias the super class' foo to be able to call it. IMO this defeats much of what makes OOP easy and elegant to use. Walter, please do it the obvious way. Lars Ivar Igesund
Mar 31 2004
next sibling parent Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Kris" <someidiot earthlink.dot.dot.dot.net> wrote:

 It's implemented the C++ way because apparently that's the target
 audience for D (rather than Java, for example).
Nothing wrong with that in itself, since people in general don't want massive changes that require re-thinking from the beginning. D is as good as it now because a lot of what we know from C++ still applies. I was able to get a simple game working in a day or two (yes, after the usual newbie mistakes, but once solved I was "up and running").
 I find the approach totally non-intuitive, and contrary to the notion
 of easy-to-learn (surely alias is considered a somewhat 'advanced'
 topic, if not downright arcane?).
IMO, you shouldn't be forced to use alias (or anything else) for normal code. A language should work as expected by a typical user, which is one area where C++ falls on its face, and where D can outshine it. The Java approach is more sensible and workable in the real world -- of the two, I would almost always choose Java's way over C++ (where they are comparable). I suspect that this overload behavior may already be engrained in D, however.
 Personally, I think pandering to C++ history is the wrong approach.
 Walter has already sidestepped a lot of the nonsense introduced by
 Bjarne-The-Toker ... this is one of the last vestiges, and needs some
 further excising. 
I couldn't agree more. -- dave
Mar 31 2004
prev sibling parent reply John Reimer <jjreimer telus.net> writes:
Kris wrote:

 It's implemented the C++ way because apparently that's the target audience
 for D (rather than Java, for example).
 
 I find the approach totally non-intuitive, and contrary to the notion of
 easy-to-learn (surely alias is considered a somewhat 'advanced' topic, if
 not downright arcane?).
 
 Personally, I think pandering to C++ history is the wrong approach. Walter
 has already sidestepped a lot of the nonsense introduced by
 Bjarne-The-Toker ... this is one of the last vestiges, and needs some
 further excising.
 
 - Kris
The use of alias may be an ugly solution, I'll give it that. But I think the whole situation is ugly. In Java, it could be unclear which overloaded class is being called. In that respect,in D at least, the alias makes things much more clear about what's going on and what the programmer intends to do (unless the programmer using the class doesn't know that the alias exists -- that could confuse expected results). If you want to use a superclass method as the defualt, why was it overriden in the first place (other than adopting previous functionality in the subclass)? In solving these issues, it seems more important to design a project well in order to avoid such kludges. But, I guess, sometimes these things are unavoidable, in which case, explicit aliasing may be just barely excusable. Though, like I mentioned above, it still requires the programmer to know that a Java style overloading method is being simulated. If he/she doesn't know and only understands the D rules, aliasing could also be dangerous territory. But my experience in this is inadequate; so, as usual, I'm probably missing something. -John
Mar 31 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"John Reimer" wrote:
 <snip snip snip>
 But, I guess, sometimes these things are unavoidable, in which case,
 explicit aliasing may be just barely excusable.
I ran into this particular problem with Dsc.io, where various readers/writers overload a superclass method with another of the same basic name (put/get, opShl/opShr). Sometimes that sub-implementation changes the behavior of the super-method with the exact signature: for example, DisplayWriter prints a char[] in readable format, whereas Writer (binary version) emits the length first. Other times you just want to add a new signature with the same basic method name as the superclass already has (get/put etc...). For example: put(SomeClass sc) rather than the superclass put(int). Even after Walter showed me how to resolve this (and fixed a 0.81 bug), I still fail to grok the alias semantics coherently. Perhaps I'm not nearly as smart as I thought I was ... <g> - Kris
Mar 31 2004
parent reply John Reimer <jjreimer telus.net> writes:
 I ran into this particular problem with Dsc.io, where various
 readers/writers overload a superclass method with another of the same
 basic name (put/get, opShl/opShr).
 
 Sometimes that sub-implementation changes the behavior of the super-method
 with the exact signature: for example, DisplayWriter prints a char[] in
 readable format, whereas Writer (binary version) emits the length first.
 
 Other times you just want to add a new signature with the same basic
 method name as the superclass already has (get/put etc...). For example:
 put(SomeClass sc) rather than the superclass put(int).
 
 Even after Walter showed me how to resolve this (and fixed a 0.81 bug), I
 still fail to grok the alias semantics coherently. Perhaps I'm not nearly
 as smart as I thought I was ... <g>
 
  - Kris
Ok, I now see your points fairly clearly after looking over Dsc.io and your explanation. Apparently you have experienced the pain of this issue that I had not :-). If I'm correct, the system D uses is an all or nothing approach. You can't can't just merrily replace selected superclass methods in the subclass and expect the fallback superclass methods to work when called. You basically have to rewrite every method of the superclass in the subclass; for superclass calls you want to use, you have to explicitly call them (a la alias). This does make the D way quite tedious. I guess I can see how a lazy java methodology might attract people ;-). It's amazing confusing these issues can be... Later, John
Apr 01 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
On Thu, 01 Apr 2004 21:52:10 -0800, John Reimer <jjreimer telus.net>
wrote:

 I ran into this particular problem with Dsc.io, where various
 readers/writers overload a superclass method with another of the same
 basic name (put/get, opShl/opShr).
 
 Sometimes that sub-implementation changes the behavior of the super-method
 with the exact signature: for example, DisplayWriter prints a char[] in
 readable format, whereas Writer (binary version) emits the length first.
 
 Other times you just want to add a new signature with the same basic
 method name as the superclass already has (get/put etc...). For example:
 put(SomeClass sc) rather than the superclass put(int).
 
 Even after Walter showed me how to resolve this (and fixed a 0.81 bug), I
 still fail to grok the alias semantics coherently. Perhaps I'm not nearly
 as smart as I thought I was ... <g>
 
  - Kris
Ok, I now see your points fairly clearly after looking over Dsc.io and your explanation. Apparently you have experienced the pain of this issue that I had not :-). If I'm correct, the system D uses is an all or nothing approach. You can't can't just merrily replace selected superclass methods in the subclass and expect the fallback superclass methods to work when called. You basically have to rewrite every method of the superclass in the subclass; for superclass calls you want to use, you have to explicitly call them (a la alias). This does make the D way quite tedious. I guess I can see how a lazy java methodology might attract people ;-).
My rule of thumb is to use alias when I want to overload something from another class or module. You can suck in all the methods you want just using one or two alias lines. For example: class A { void bar(double x){printf("in A\n");} void bar(char[] x){printf("in A: %.*s\n",x);} } class B:A { alias A.bar bar; void bar(int x){printf("in B\n");} } int main() { B a=new B(); a.bar(1); a.bar(1.0); a.bar("hello"); return 0; } Alias is your friend :-)
It's amazing confusing these issues can be...

Later,

John
Apr 02 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
Ben Hinkle wrote:

 
 My rule of thumb is to use alias when I want to overload something
 from another class or module. You can suck in all the methods you
 want just using one or two alias lines. For example:
 
 class A
 {
     void bar(double x){printf("in A\n");}
     void bar(char[] x){printf("in A: %.*s\n",x);}
 }
 class B:A
 {
     alias A.bar bar;
     void bar(int x){printf("in B\n");}
 }
 
 int
 main()
 {
     B a=new B();
     a.bar(1);
     a.bar(1.0);
     a.bar("hello");
     return 0;
 }
 
 
 Alias is your friend :-)
 
Ah ha! I do see it now. Thanks!
Apr 02 2004
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote:

[...]
 Alias is your friend :-)
[...] Agreed. However, it can become tedious to provide an alias for every function, that I want to overload that way. D already has syntactic sugar in several cases. For example the static attribute for a single declaration can be extended by prepending it to a block of declarations or all of the following declarations, except overridden by another attribute. So long!
Apr 02 2004
prev sibling parent reply Brad Anderson <brad dsource.dot.org> writes:
Lars Ivar Igesund wrote:
 I admit that I expected D to function as Java in this regard.
 My opinion now is that D's spec has a bug. It should NOT be
 necessary to alias the super class' foo to be able to call it.
Ouch, I must have missed Ben's post earlier about this. It will make the port of SWT --> DWT a real pain in the ass. I was also (incorrectly) assuming that you could overload away. I'll have to agree with the rest of the thread that, even though it doesn't phase the C++ people, Java may have a more intuitive solution here. Besides, D will not only win over a lot of C++'ers. 3 million Java programmers are going to look at D and think "Wow, I can compile it? Sweet!" BA
Mar 31 2004
parent reply Brad Anderson <brad dsource.dot.org> writes:
Sorry about the self-post...

Brad Anderson wrote:
 3 million Java programmers are going to look at D and think "Wow, I can
compile 
 it?  Sweet!"
Okay, maybe not all 3 million will look, but hopefully a lot. And I meant 'compile it natively' BA
Mar 31 2004
parent reply John Reimer <jjreimer telus.net> writes:
 
 
 Okay, maybe not all 3 million will look, but hopefully a lot.  And I 
 meant 'compile it natively'
 
 BA
Well, I'm expecting there's going to be a lot of hidden problems that will need to fixed once the compile/link phase is complete. I don't know how this particular issue will affect the SWT port; I'm thinking that when class methods are called with the correct number of arguments, the intuitive meaning is that the most recent subclass method (of the same name) is going to be called. It's more clear to use an explicit method reference anyway. It could get confusing otherwise which method is being called. I don't know; I just think it's better to have to call b.foo() explicitly from class C if there's functionality you need from the superclass. At least people examining the code know exactly what's going on. I guess if SWT does make use of overloaded methods this way, it could be tricky to catch it and make the appropriate D conversion. But then the D code will be more readable than the Java code when it's done :-).
Mar 31 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
John Reimer wrote:

[...]
 But then the D code will be more readable than the Java code when it's
 done :-).
I totally agree with you. There was just a discussion about sequenced default valued parameters. One argument was, that the coder must simply not be aware of them, when coding. This argument holds here in the other way round: a coder might just not be aware of the fact, that he overrides a member with the same name of the superclass, because he is simply not aware of the fact, that there is one. Then providing the function call with a wrong typed argument, which causes no error, because there is a matching function in the superclass, may result in a desaster. By explicitely importing the overloaded functions the coder states, that he knows of them and wants to extend their functionality. On the other hand the current implementation provides a mechanism to block unwanted functionality. How could this achieved by a java like approach? So long!
Mar 31 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Perhaps some syntactic sugar would make this pill more palatable?

For example, one might apply the overrides keyword to the superclass like
so:

class Foo : overrides Bar
{
}

That's truly explicit, easy to learn, easy to spot and, importantly, easy
for an IDE to do something constructive with (no pun intended). The alias
stuff is black-magic in comparison, and IDE's will have a much harder time
grokking them (if they even bother).

Even better, this would be simple for Walter to add, since it's just an
alias for a specific and common usage of alias :-)

IMHO, this is one of those things that can make a language much easier to
grasp, and more consistent in its usage. That's really important in any
quest to gain mass adoption.

- Kris


"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:c4feg9$34o$1 digitaldaemon.com...
 John Reimer wrote:

 [...]
 But then the D code will be more readable than the Java code when it's
 done :-).
I totally agree with you. There was just a discussion about sequenced default valued parameters. One argument was, that the coder must simply not be aware of them, when coding. This argument holds here in the other way round: a coder might just not be aware of the fact, that he overrides a member with the same name of the superclass, because he is simply not aware of the fact, that there is one. Then providing the function call with a wrong typed argument, which causes no error, because there is a matching function in the superclass, may result in a desaster. By explicitely importing the overloaded functions the coder states, that he knows of them and wants to extend their functionality. On the other hand the current implementation provides a mechanism to block unwanted functionality. How could this achieved by a java like approach? So long!
Mar 31 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
Kris wrote:

 Perhaps some syntactic sugar would make this pill more palatable?
 
 For example, one might apply the overrides keyword to the superclass like
 so:
 
 class Foo : overrides Bar
 {
 }
 
 That's truly explicit, easy to learn, easy to spot and, importantly, easy
 for an IDE to do something constructive with (no pun intended). The alias
 stuff is black-magic in comparison, and IDE's will have a much harder time
 grokking them (if they even bother).
 
 Even better, this would be simple for Walter to add, since it's just an
 alias for a specific and common usage of alias :-)
 
 IMHO, this is one of those things that can make a language much easier to
 grasp, and more consistent in its usage. That's really important in any
 quest to gain mass adoption.
 
 - Kris
 
Very true. Something cleaner then alias, yet explicit would be desirable.
Mar 31 2004
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Kris wrote:

 Perhaps some syntactic sugar would make this pill more palatable?
[...] That is not sugar. As far as I understand you, both ways should be incorporated into D. Because the code must state that it is inherent dangerous, I would not priliminary exclude your suggestion. So long!
Mar 31 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
Why, thank you Manfred <g>

You understood me correctly: this would be the "non-expert" version of alias
usage, as applied to superclass method-overloading. Alias would still exist
in its full glory, to do everything it currently does.

- Kris

"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:c4fq3f$l9b$1 digitaldaemon.com...
 Kris wrote:

 Perhaps some syntactic sugar would make this pill more palatable?
[...] That is not sugar. As far as I understand you, both ways should be incorporated into D. Because the code must state that it is inherent dangerous, I would not priliminary exclude your suggestion. So long!
Mar 31 2004
parent Manfred Nowak <svv1999 hotmail.com> writes:
Kris wrote:

[...]
 this would be the "non-expert" version of alias usage
Now only the proof does not exist, that both paradigmas can coexist. So long!
Apr 02 2004