InvokeDynamic

[Rémi Forax]

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.latremoliere at gmail.com <mailto:daniel.latremoliere at gmail.com>
>
> //
>
>
> _______________________________________________
> 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/20110501/3e1c4f78/attachment.html