Re: Covariant Return Types

 > > In other words, do the specializations of a public method become
> part of
> >the public interface of the package, or is it enough for clients to
> know that
> >there is a method =self= with type A -> A? Is the above going to be
> equivalent to:
> >    package b;
> >    public class A { }
> >    public class B extends A { }
> >    public A self(A a) { log("A -> A"); return a; }
> >           // explicitly noted to return A
> >           A self(B b) { log("B -> B"); return b; } 
> >or, is =self= now considered to be overloaded again?
> 
> At the moment this is considered overloading. But that should
> probably change because almost everyone is used to writing return
> types when overriding some methods. And if the implementation is in a
> different source file as the definition allowing a return type when
> overriding a method can improve the readability of the code.

Yes.

> >It seems that there is a big syntactical burden (lots of
> keyboarding) to
> >requiring overriding to be explicit:
> [snipped code showing explicit overriding is a bad idea]
> 
> I think the best solution is making method definitions explicit
> (using a "method" prefix?) so that return type can be allowed at

"method"? Isn't there some real that keywords must be 3 letter?
'met' Noooo! 
'def'


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools


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