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


begin 0644 inheritance1.d




`
end
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:











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