change invokeGeneric to invoke in MethodHandle?

[Raffaello Giulietti]

Do that!
+1

Raffaello

On Sun, Mar 27, 2011 at 08:27, Jeroen Frijters <jeroen at sumatra.nl> wrote:
> +1 invoke makes sense.
>
>> -----Original Message-----
>> From: mlvm-dev-bounces at openjdk.java.net [mailto:mlvm-dev-
>> bounces at 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 at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>