Method reference controversy

Zdenek Tronicek tronicek at fel.cvut.cz
Mon May 19 01:15:03 PDT 2008


Ok. I will wait for your blog. So now just a few words what I find  
controversial:

class APIClass {
   static void m(Object o) { }
}

Your code:

{ String => void } pp3 = APIClass#m(String);

Another version of API:

class APIClass {
   static void m(Object o) { }
   static void m(String s) { }
}

Your code remains the same, but now refers to another method.

Z.
-- 
Zdenek Tronicek
Department of Computer Science and Engineering
Prague                   tel: +420 2 2435 7410
http://cs.felk.cvut.cz/~tronicek


Quoting Neal Gafter <neal at gafter.com>:

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







More information about the closures-dev mailing list