Typed Method handles

[Ali Ebrahimi]

Hi Remi,

On Thu, Jun 9, 2011 at 5:59 PM, Rémi Forax <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>  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>  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?

Best Regards,
Ali Ebrahimi