bug: method override via overload

[pragma]

In article <dtf9t2$1vjk$1 at digitaldaemon.com>, Ant says...
>
>In article <dtcpkd$23ii$1 at digitaldaemon.com>, Nick says...
>>
>>In article <dtcoqg$22lv$1 at digitaldaemon.com>, pragma says...
>>>
>>># typedef int Foo;
>>># 
>>># class Gorf{
>>># 	public void bar(int x){} // return type here is immaterial (try 'int')
>>># }
>>># 
>>># class Goat : Gorf{
>>># 	public int bar(Foo x){}
>>># }
>>># 
>>># void main(){
>>># 	Foo y = 0;
>>># 	int z = 0;
>>># 	Goat g = new Goat();
>>># 	g.bar(y); // works
>>># 	g.bar(z); // fails
>>># }
>>
>>This is by design, not a bug. When you introduce members with the same name in a
>>child class, you automatically hide the inherited name from the parent. There
>>are good reasons to do this
>
>Where are those?

Exactly what I'm trying to figure out. ;)

BTW, thank you Nick: your suggested workaround via 'alias' worked great.

Anyway, my main problem with this behavior is that if Foo were a class, the code
in main() would compile and behave just fine.  So why such an inconsistency
could be tolerated, is beyond me.

Also the docs say (for the most part) that this shouldn't happen:

"Strong types can be introduced with the typedef. Strong types are semantically
a distinct type to the type checking system, for function overloading, and for
the debugger."

# typedef int myint;
#
# void foo(int x) {  }
# void foo(myint m) {  }
#
# myint b;
# foo(b);	        // calls foo(myint)

So it works fine with overloads in the same scope, but fails when typedefs
overlap with inherited methods that posess the same underlying type.  That
smells like a bug to me.

- Eric Anderton at yahoo