+1 Seems like a natural choice.
On 2011-03-26, at 6:08 PM, John Rose <john.r.r...@oracle.com> wrote: > 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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
