Hi Daniel,
On 04/30/2011 09:51 AM, Daniel Latrémolière wrote:
I suggest a syntax for InvokeDynamic.
Why ?
motivations ?
It is created like a field and has a name (for referencing and
bootstrapping it), then i suggest to create a new modifier "dynamic"
and define InvokeDynamic like a mix of field and constructor with his
bootstrap code included in it, like this:
|{public|protected||private} {static||*dynamic*} {final||volatile}
$name*(MethodHandles.Lookup caller, MethodType type)* {
// code creating MethodHandle "value" variable.
*target* value;
}|
You can see the three following differences with a field:
* A new modifier ("dynamic") usable in the same places than
current "static" modifier. All others modifiers are like a
standard field.
* The field has arguments like a constructor with his execution
context. The two arguments of the bootstrap/constructor are fixed.
* In this type of dynamic field constructor, the normal (without
exception) end of code is "target" instruction.
The bootstrap method return a MethodHandle, because the type of
CallSite is not used given the others modifiers of the field definition:
* final => ConstantCallSite
* "nothing" => MutableCallSite
* volatile => VolatileCallSite
Given this syntax, there is no need (except for reflection) of
exposing CallSite and using a bootstrap method (no name wasted for
referencing another bootstrap method).
You forget an important part of the design, developers can subclass a
CallSite (actually one of the 3 subclasses).
Also, the name use for the bootstrap method can be forged by the code
generator,
by example: 'ruby:call' is a valid invokedynamic name that encodes a
kind of namespace in it.
For the eye of developer, this will visibly be a dynamic field with a
constructor, then reasonably corresponds to InvokeDynamic features.
Opinions?
Daniel.
NB: It is not special in Java to have different content in a code
following context: a constructor allow instructions like "this(...)",
or "super(...)", contrary to a standard method, then "target"
instruction at the end of code will not be really alien.
Rémi
--
Daniel Latrémolière
Mail: daniel.latremoli...@gmail.com <mailto:daniel.latremoli...@gmail.com>
//
_______________________________________________
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
