+1 invoke makes sense.
> -----Original Message----- > From: mlvm-dev-boun...@openjdk.java.net [mailto:mlvm-dev- > boun...@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@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
