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