Do that! +1 Raffaello
On Sun, Mar 27, 2011 at 08:27, Jeroen Frijters <jer...@sumatra.nl> wrote: > +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 > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
