InvokeDynamic

[Daniel Latrémolière]

>> I suggest a syntax for InvokeDynamic.
>>
> Why ?
> motivations ?
Because it seems that syntax for InvokeDynamic will not be available in 
JDK7 and I dislike generating bytecode.
I have used ASM, some years ago, and have nothing against it, but now I 
do not like Java bytecode (stack machine) and the concept of bytecode 
generation:
- Multi-step code building introduces problems/syntactic sugar, when 
source code need using/referencing generated code (then some sort of 
service registration/inversion of control adding weight only because 
bytecode generation, or intricated build process).
- I think there is more elegant partial solutions, than bytecode 
generation even with less power. By example, parametrized classes is a 
problem easily solvable by bytecode generation, but more beautiful with 
generics (even if it can be more useful without erasure, but Java 
compatibility would possibly be more problematic).
- Bytecode generation create a big quantity of names (overload of names 
without a specific semantic): Is an infinite number of names of the 
following form ListOfObject, ListOfString, ListOfInteger, 
ListOfMyStupidClass, etc. more understandable than only one standard 
name List used as template: List<Object>, List<String>, List<Integer>, 
List<MyStupidClass>? Not, for me.

> 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.
Sorry,
Please forget my proposal (I have no time to adapt it).

Just for explanation: I personally think defining classes for modifiers 
like {final||volatile} is abusive naming and not modular development (my 
Java-vision). I prefer reusing Java modifiers even by adding specific 
predefined variables in code of method or inner class (e.g. caller like 
this, super) if useful in the context.

Only my opinion,
Daniel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110501/89ffb215/attachment.html