change invokeGeneric to invoke in MethodHandle?

[Jeroen Frijters]

+1 invoke makes sense.

> -----Original Message-----
> From: mlvm-dev-bounces at openjdk.java.net [mailto:mlvm-dev-
> bounces at openjdk.java.net] On Behalf Of John Rose
> Sent: Saturday, March 26, 2011 10:08 PM
> To: Da Vinci Machine Project
> Subject: change invokeGeneric to invoke in MethodHandle?
> 
> One bit of review feedback we've gotten is our choice of names for the
> "front door" methods of MethodHandle, "invokeExact" and "invokeGeneric".
> 
> There is good consensus for "invokeExact" as a special case of the more
> generic invocation type called "invokeGeneric".  But the name
> "invokeGeneric" is more problematic.
> 
> First, it seems to mention "generics", even though it has nothing to do
> with Java generic types (except that it can dynamically supply the casts
> that the erasure technique sometimes requires).
> 
> Second, the term "generic" doesn't have any other meaning, other than
> "this is somehow more general than the exact version".
> 
> There are two alternatives to "generic".  One is to find the word or
> phase that we should have picked instead of "generic", such as
> "polymorphic" or "withConversions".  The other is to drop the word, and
> use just "invoke".
> 
> Some of us on the EG (including me) are inclined to go with plain
> "invoke".  Does anyone see a problem with this?
> 
> Benefits:
>  - makes typical code examples (documents, slides, pedagogy) easier to
> write and read
>  - strengthens the analogy with JVM terminology, JLS terminology,
> reflection, etc.
>  - "exact" functions as an extra type-match requirement/assertion
> (asymmetry with "invokeExact" is not a problem)
>  - the terms nest nicely: one can speak of "method handle invocation"
> and when needed of "exact invocation"
> 
> Comments?
> 
> -- John
> 
> P.S.  Some background, as a reminder:
> 
> http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-pr/  (OpenJDK
> doc snapshot for Public Review)
> 
> The difference between the two "front doors" is that "invokeExact"
> requires the same descriptor matching that the native JVM invoke
> instructions require, while "invokeGeneric" is a strict superset,
> allowing certain simple conversions on arguments and return values.
> 
> The two-door model here allows implementors to choose native JVM strict
> typing (invokeExact) or a flexible simulation of argument conversions,
> approximately as allowed in the Java language.  The invokeExact call is
> useful for systems that do not want accidental introduction of runtime
> argument transformations, while the invokeGeneric call is probably most
> useful for end users.  (It also has benefits for building some kinds of
> method handle transformations.)
> 
> There is actually a third "door" which is a garden-variety "varargs"
> method MethodHandle.invokeWithArguments.  It is supposed to have a long
> name, to hint that it is not your first choice, because it is guaranteed
> to do all possible boxing steps.  Indeed, it is more closely akin to
> java.lang.reflect.Method.invoke than MethodHandle.invokeGeneric, but for
> that reason it is *not* the primary entry point for method handle
> invocation.  The main use for it is to apply a method handle to a pre-
> existing array of arguments.
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev