)?
3. Are there plans to add MethodHandle literals, e.g. Class#method( types )?
4. Assuming 3 above; are there plans for a binding literal, e.g.
MethodHandle addA = String#concat( String, A )?
I am sure these items have been already discussed in the expert group,
just wondering what the latest
the latest thinking is.
-- Howard.
cheers,
Rémi
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
already discussed in the expert group,
just wondering what the latest thinking is.
The 292 expert group has enough to worry about without also getting into
language design wars. Just keeping up with lambda-dev is probably a full-time
job.
-- John
Le 22/06/2010 22:46, John Rose a écrit :
On Jun 22, 2010, at 1:32 PM, John Rose wrote:
The small amount of support in javac for 292 is a low-level punch-through to
allow assembly-level programming.
A little more detail: Here's the sort of thing I'm experimenting with, for
On Jun 22, 2010, at 2:25 PM, Rémi Forax wrote:
There is another possible design.
Allow users to create fake types like java.dyn.Invokedynamic
and define the annotation on that type.
I'd rather not let the magic signature polymorphism escape beyond the current
set of names (InvokeDynamic and
Le 22/06/2010 23:29, John Rose a écrit :
On Jun 22, 2010, at 2:25 PM, Rémi Forax wrote:
There is another possible design.
Allow users to create fake types like java.dyn.Invokedynamic
and define the annotation on that type.
I'd rather not let the magic signature polymorphism
On Jun 22, 2010, at 4:24 PM, Howard Lovatt wrote:
I don't think there is confusion between a type name and a value,
therefore proposed syntax OK (but maybe not the preferred). If you
want a class you have to append '.class'.
Sorry, that would be a breaking change to the language, not an