Re: Covariant Return Types

Hi,

Getting back to some questions that were left unanswered:

> Okay, but try this version:
> 
>     package c;
>     interface A { }
>     interface B { }
>     A doSomething(A a) { ... }
>     B doSomething(B b) { ... }
> 
>     package d;
>     import c;
>     class C implements A, B { }
>     override c.doSomething(C a) { ... }
> 
> Now, does d.doSomething(C) override c.doSomething(A) or c.doSomething(B)? 

It's ambiguous, and the compiler will report the ambiguity. The way you 
can resolve the ambiguity, in the current version, is:

doSomething(C(A) a) { ... }

Which means: this is an implementation of doSomething when 'a' is an 
instance of C, for a doSomething method that accepts an argument of type A.

I actually think that this syntax could be replaced by a more general 
construct:

doSomething(C & A  a) { ... } // no advertising intended!

This would also allow to solve ambiguities, and additionally allow you 
to declare an implementation for objects that implement two different 
interfaces. This was discussed concerning a redesign of the collection 
hierarchy that would be entirely type safe (no unsupported opertations).


> Also, notice that when the package name is long, it is ugly to provide many
> specializations using that syntax.

You don't need to write the package name, you can use the short method 
name. You can (will be able to) decide to write the full name if that 
helps reading (in the same way you can decide whether to fully qualify 
class names or not), or to disambiguate.

Daniel



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click