[jsr-292-eg] Conversion of method reference to MethodHandle
blackdrag at gmx.org
Mon Dec 31 04:16:02 PST 2012
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
> - 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
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?
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
More information about the lambda-spec-experts