change invokeGeneric to invoke in MethodHandle?

[Mark Roos]

FWIW Go with invoke.  The use of the modifier 'generic' was  confusing to 
me, which led  me to
selecting  invokeExact  as I assumed it would be faster than something 
which
was potentially doing unnecessary conversions. 


regards
mark





From:
John Rose <john.r.rose at oracle.com>
To:
Da Vinci Machine Project <mlvm-dev at openjdk.java.net>
Date:
03/26/2011 02:09 PM
Subject:
change invokeGeneric to invoke in MethodHandle?
Sent by:
mlvm-dev-bounces at openjdk.java.net



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110326/d1ad0c51/attachment.html