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

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

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.

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

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

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

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