www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - BUG: D Inheritance Error - inheritance1.d

reply D. Trebbien <D._member pathlink.com> writes:
Compiling the attached code gives these error messages:

inheritance1.d(18): function inheritance1.B.test () does not match argument type
s (int)
inheritance1.d(18): Error: expected 0 arguments, not 1

Shouldn't this code compile?

----Attached code provided below for reference----
class A
{
void test(int val)
{
}
}

class B : A
{
void test()
{
}
}

int main(char[][] args)
{
B b=new B();
b.test(6);

return 0;
}
Feb 27 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 28 Feb 2005 00:33:15 +0000 (UTC), D. Trebbien wrote:

 Compiling the attached code gives these error messages:
 
 inheritance1.d(18): function inheritance1.B.test () does not match argument
type
 s (int)
 inheritance1.d(18): Error: expected 0 arguments, not 1
 
 Shouldn't this code compile?
 
 ----Attached code provided below for reference----
 class A
 {
 void test(int val)
 {
 }
 }
 
 class B : A
 {
 void test()
 {
 }
 }
 
 int main(char[][] args)
 {
 B b=new B();
 b.test(6);
 
 return 0;
 }

No this is not a bug. As Walter has decided,the rule for locating candidate methods is based firstly on the NAME of the method within the scope, then secondly based on the signature of such methods. In your case, the B class only defines (in the scope of B) a 'test()' and does not assume that you mean A.test when you use 'b.test(6)'. In other words, inheritance is not implicit, you have to be explicit in the cases where there are same-named methods inside parent classes. However, its not too hard to do. All you need is to let the compiler know that it can also use class A's test(int) routine from within the scope of B. Recode class B thus ... class B : A { alias A.test test; // Tell B about A's test. void test() { } } It should all compile fine now. Note that if A's test had a different name (eg. testA) and you had of coded 'b.testA(6)' it would have compiled. The error message only happens when you have a name clash without explicit resolution in place. For example, an alternate way of doing this would have been to code 'b.A.test(6)', thus resolving the ambiguity for this code line only. The 'alias' resolves it for all lines of code. -- Derek Melbourne, Australia 28/02/2005 11:52:04 AM
Feb 27 2005
parent reply D. Trebbien <D._member pathlink.com> writes:
That's interesting. The fix seems rather silly, though.

In article <1tsuugq13mwdn$.i06n0wm04hvi$.dlg 40tude.net>, Derek Parnell says...
On Mon, 28 Feb 2005 00:33:15 +0000 (UTC), D. Trebbien wrote:

 Compiling the attached code gives these error messages:
 
 inheritance1.d(18): function inheritance1.B.test () does not match argument
type
 s (int)
 inheritance1.d(18): Error: expected 0 arguments, not 1
 
 Shouldn't this code compile?
 
 ----Attached code provided below for reference----
 class A
 {
 void test(int val)
 {
 }
 }
 
 class B : A
 {
 void test()
 {
 }
 }
 
 int main(char[][] args)
 {
 B b=new B();
 b.test(6);
 
 return 0;
 }

No this is not a bug. As Walter has decided,the rule for locating candidate methods is based firstly on the NAME of the method within the scope, then secondly based on the signature of such methods. In your case, the B class only defines (in the scope of B) a 'test()' and does not assume that you mean A.test when you use 'b.test(6)'. In other words, inheritance is not implicit, you have to be explicit in the cases where there are same-named methods inside parent classes. However, its not too hard to do. All you need is to let the compiler know that it can also use class A's test(int) routine from within the scope of B. Recode class B thus ... class B : A { alias A.test test; // Tell B about A's test. void test() { } } It should all compile fine now. Note that if A's test had a different name (eg. testA) and you had of coded 'b.testA(6)' it would have compiled. The error message only happens when you have a name clash without explicit resolution in place. For example, an alternate way of doing this would have been to code 'b.A.test(6)', thus resolving the ambiguity for this code line only. The 'alias' resolves it for all lines of code. -- Derek Melbourne, Australia 28/02/2005 11:52:04 AM

Feb 27 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"D. Trebbien" <D._member pathlink.com> wrote in message 
news:cvts4s$1adn$1 digitaldaemon.com...
 That's interesting. The fix seems rather silly, though.

It might seem silly for a simple case like this one, but for large systems where the superclass might be many inheritance levels up it wouldn't be obvious at all that B.test and A.test overload each other. Plus imagine the bugs that creep in when A.test accepts a uint and B.test accepts an int. D avoid all those bugs by making the code be explicit about overloading. c'est la D.
 In article <1tsuugq13mwdn$.i06n0wm04hvi$.dlg 40tude.net>, Derek Parnell 
 says...
On Mon, 28 Feb 2005 00:33:15 +0000 (UTC), D. Trebbien wrote:

 Compiling the attached code gives these error messages:

 inheritance1.d(18): function inheritance1.B.test () does not match 
 argument type
 s (int)
 inheritance1.d(18): Error: expected 0 arguments, not 1

 Shouldn't this code compile?

 ----Attached code provided below for reference----
 class A
 {
 void test(int val)
 {
 }
 }

 class B : A
 {
 void test()
 {
 }
 }

 int main(char[][] args)
 {
 B b=new B();
 b.test(6);

 return 0;
 }

No this is not a bug. As Walter has decided,the rule for locating candidate methods is based firstly on the NAME of the method within the scope, then secondly based on the signature of such methods. In your case, the B class only defines (in the scope of B) a 'test()' and does not assume that you mean A.test when you use 'b.test(6)'. In other words, inheritance is not implicit, you have to be explicit in the cases where there are same-named methods inside parent classes. However, its not too hard to do. All you need is to let the compiler know that it can also use class A's test(int) routine from within the scope of B. Recode class B thus ... class B : A { alias A.test test; // Tell B about A's test. void test() { } } It should all compile fine now. Note that if A's test had a different name (eg. testA) and you had of coded 'b.testA(6)' it would have compiled. The error message only happens when you have a name clash without explicit resolution in place. For example, an alternate way of doing this would have been to code 'b.A.test(6)', thus resolving the ambiguity for this code line only. The 'alias' resolves it for all lines of code. -- Derek Melbourne, Australia 28/02/2005 11:52:04 AM


Feb 27 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Ben Hinkle wrote:
 "D. Trebbien" <D._member pathlink.com> wrote in message 
 news:cvts4s$1adn$1 digitaldaemon.com...
 
That's interesting. The fix seems rather silly, though.

It might seem silly for a simple case like this one, but for large systems where the superclass might be many inheritance levels up it wouldn't be obvious at all that B.test and A.test overload each other. Plus imagine the bugs that creep in when A.test accepts a uint and B.test accepts an int. D avoid all those bugs by making the code be explicit about overloading. c'est la D.

Being explicit about the overloading can mean a whole lot of typing in big projects. It prevents bugs on one hand and adds a significant amount of work on the other; that's where it ends up looking hackish. At the very least, there should be a keyword to specify for the class the ability to pull all superclass methods into the current subclass: # class A # { # void test(int A) {} # } # # class B : overload A # { # void test() {} # } Perhaps a better/less confusing keyword could be thought up by the more creative minds of this list. If the programmer /wants/ to use all methods of the superclass, then he should be able to enable those methods without spending an onerous session with alias entries. Alias' would still serve a purpose for cases where a minimum of superclass methods need to be added. In it's current state, D seems to represent a design oriented towards procedural C, with OO as an "option" -- but not a significantly competitive option. I think D has to push its own boundaries a little and make that option potent. - JJR
Feb 27 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
John Reimer <brk_6502 yahoo.com> wrote:

[...]
 If the programmer /wants/ to use all methods of the superclass,
 then he should be able to enable those methods without spending
 an onerous session with alias entries.

No programmer can want to use all methods, because she/he might not know what these methodes are, especially in the case, that the superclass is redesigned between finish and restart of the design of the current class. -manfred
Feb 28 2005
parent John Reimer <brk_6502 yahoo.com> writes:
On Mon, 28 Feb 2005 08:40:36 +0000, Manfred Nowak wrote:

 John Reimer <brk_6502 yahoo.com> wrote:
 
 [...]
 If the programmer /wants/ to use all methods of the superclass,
 then he should be able to enable those methods without spending
 an onerous session with alias entries.

No programmer can want to use all methods, because she/he might not know what these methodes are, especially in the case, that the superclass is redesigned between finish and restart of the design of the current class. -manfred

Fair enough.
Feb 28 2005