Typed Method handles

[Rémi Forax]

On 06/09/2011 04:46 PM, Ali Ebrahimi wrote:
> Hi Remi,
>
> On Thu, Jun 9, 2011 at 5:59 PM, Rémi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     On 06/09/2011 04:11 PM, Ali Ebrahimi wrote:
>     > Hi Remi,
>     >
>     >
>     > On Thu, Jun 9, 2011 at 4:49 PM, Rémi Forax<forax at univ-mlv.fr
>     <mailto:forax at univ-mlv.fr>>  wrote:
>     >
>     >>   On 06/09/2011 12:33 PM, Ali Ebrahimi wrote:
>     >>
>     >> Hi Remi,
>     >> comments inlined.
>     >>
>     >> On Thu, Jun 9, 2011 at 1:49 PM, Rémi Forax<forax at univ-mlv.fr
>     <mailto:forax at univ-mlv.fr>>  wrote:
>     >>
>     >>> On 06/09/2011 11:55 AM, Ali Ebrahimi wrote:
>     >>>> Hi all,
>     >>>> What happens if method handles takes variable arty of generic
>     type
>     >>>> parameters.
>     >>>>
>     >>>> MethodHandle<void,int>   mh = #{x ->   System.out.println(x);};
>     >>>>
>     >>>> mh.invokeExack(1); //compiles
>     >>>>
>     >>>> mh.invokeExack("1"); //compile fail
>     >>>   I've proposed this syntax last year or before.
>     >>> There are 2 problems:
>     >>>   - it's a function type, so this means to introduce a new
>     kind of type
>     >>> in the Java type system.
>     >>>   - it allows to use void and the primitives types between the
>     angle
>     >>> bracket
>     >>>     which is not something allowed for the generics syntax.
>     >>>
>     >> This is not so hard. Method handles are new phenoms to platform and
>     >> compiler can handle them specially as polymorphic signature method
>     >> invocations handed.
>     >>
>     >> Best Regards,
>     >> Ali Ebrahimi
>     >>
>     >>   So this syntax was rejected for Java 8 but may be
>     reconsidered later.
>     >>> Rémi
>     >>>
>     >> I think I know what a method handle is.
>     >> Polymorphic signature method like MH.invoke or MH.invokeGeneric
>     are handled
>     >> by bypassing the method resolution used by the compiler.
>     >> That's why you have to specify the return type when calling
>     such methods.
>     >> To summarize, the compiler does nothing and let the VM checks
>     at runtime if
>     >> the invocation is safe or not.
>     >>
>     >> So you can't reuse this mechanism to implement function type.
>     >>
>     > I don't mean reuse the same mechanism, my intent is specially
>     applying of
>     > generic type parameters for MethodHandle reference types and
>     allowing them
>     > take arbitrary number of  type parameters in declaration.
>     > In this case, the compiler does not check number and types of
>     them and
>     > accept them as is and use them for checking of methodhandle
>     invocation
>     > expresions .
>     >
>     > MethodHandle<void,int>   mh1;
>     > MethodHandle<void,int,int>   mh2;
>     > MethodHandle  mh;
>     > ...
>     > mh1.invoke(1);
>     > mh2.invoke(1,2);
>     >
>     > for generic MethodHandle reference as mh1, mh2 compiler checks
>     applicability
>     > of passed args in methodhandle invocation expresions and for
>     non-generic
>     > once as mh don't do this check and works as current mechanism.
>     > mh.invoke(1,2,3,4);
>     >
>     > MethodHandle class itself does not any generic type parameters in
>     > definition.
>
>     But you just scratch the surface.
>     What about sybtyping between MethodHandle function type,
>     is a MethodHandle function type is a reified type,
>     is wildcard of MethodHandle function type allowed, is capture allowed,
>     is a MethodHandle function type can be inferred (what are the rules
>     for such inference), etc ?
>
> I think, this idea is in raw state and each of the above cases should 
> be investigated. At first some of them can be supported. But any 
> solution must be possible forward compatible to kill the rest of the 
> battle.
>
> What do you think?

[me trying to remember some shower session about that]
I think you first need reification of generics if you want to be sure to 
don't introduce hazard.

After, you just have to create a JSR :)

>
> Best Regards,
> Ali Ebrahimi
>

regards,
Rémi