Method reference controversy

[Neal Gafter]

There are two answers to this.  Technically, they way I expect to specify
method references is by resolving a method invocation with the givem
argument types, not by "looking up" a method of precisely the given
signature.  The second answer is why.  This is more flexible in allowing a
level of both binary and source compatibility as an API (which the
method-reference is referencing) evolves.  This probably deserves a much
longer explanation; I'll put it on my list of topics to blog about.  It has
other tertiary benefits as well, such as allowing intentional restrictions
on the argument types and allowing reference to generic methods.

On Mon, May 19, 2008 at 12:40 AM, Zdenek Tronicek <tronicek at fel.cvut.cz>
wrote:

> Hi,
>
>    static void m(Object o) { }
>
> we can refer to the m method as follows
>
>    { Object => void } pp1 = CovariantEtaControversy#m(Object);
>
> There is also a useful conversion so that we can use
>
>    { String => void } pp2 = CovariantEtaControversy#m(Object);
>
> But why is allowed the following?
>
>    { String => void } pp3 = CovariantEtaControversy#m(String);
>
> The method refered is always determined at compilation time. So, I find
> this a little confusing.
>
> Zdenek
> --
> Zdenek Tronicek
> Department of Computer Science and Engineering
> Prague                   tel: +420 2 2435 7410
> http://cs.felk.cvut.cz/~tronicek <http://cs.felk.cvut.cz/%7Etronicek>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080519/73be9f76/attachment.html