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
