[jsr-292-eg] Conversion of method reference to MethodHandle

[Jochen Theodorou]

Am 31.12.2012 01:42, schrieb Remi Forax:
[...]
> For the semantics:
>    Unlike the method reference with a functional interface, only
> unbunded method reference are allowed, so by example,
>    a method reference starting with an expression or super are not valid.
>    Moreover, because there is no type information that the compiler can
> extract from a MethodHandle, the semantics in case of several
> overloading methods, i.e. several applicable methods is simple, it's an
> ambiguity and is rejected by the compiler.
>    More formally, a method reference can be converted to a
> j.l.i.MethodHandle,
>      - only if it's form is
>         Type::name, with Type an existing type and name a valid Java
> identifier or 'new'.
>      - then from the type, the compiler gather all accessible methods
> declared in the type type or it's super type (class or interfaces),
>        if a method is override-equivalent to another one, the one from
> the supertype is discarded.
>        if the name is 'new', the compiler gather all constructors of the
> type type.
>        if the type is an array, all public methods of j.l;Object are
> available plus clone()
>      - if there are more than one method in the set of gathered method,
> the reference is ambiguous.
>      - if there is no method, the reference is not available
>      - if there is one method, a method handle will be created from this
> method.

I think not allowing overloaded methods will restrict the usage quite a 
lot. You say this should be able to reference constructors, but having 
more than one constructor is a very common thing. Also you don't specify 
visibility. what if for example there are two X::foo, but one is private 
the other not? does it still count as overloaded? Will we be allowed to 
call the other? Since you talk of simplified method selection logic I 
would assume it is not seen as overloaded, if the private method is not 
visible. That would at least in same cases save the usage for this. But 
I still think you should be able to give the parameter types. Actually 
being able to give the return type too would be even better for 
languages that are not Java. X:foo could be a short form if there is no 
overloading... or is x:foo(String) difficult to implement?

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org