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

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

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

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

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

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

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.