2009/11/27 <[email protected]>: > Selon Rémi Forax <[email protected]>: > >> Perhaps the unability to capture (non-final ?) variables is against the >> tradition but the main >> use cases for closures in Java is the ability to express blocks of codes >> that will run in parallel. > > And we all know that "final" is a synonym for "immutable" ... > No offense intended, but I had a good laugh.
Nitpick but final is a synonym for 'being assigned a value at most once" which is quite different to "immutable". That is to say that a final variable can have up to two values in its lifetime. One is the default value for that data type the second is the value it is assigned at initialisation (the initialisation may never happen because of an exception being thrown). The Java closure spec will have to take this into account (like the inner class spec already does). The final attribute is not enforced by the JVM so some non Java languages can (I believe) cause odd things to happen with values declared final in Java. Pedantry aside:) I think the major interest of non Java language designers and implementers on the JVM is to ensure that the Java Closure spec allows their Closures/Lambdas to appear as Java Closures to Java and Java Closures appear as Closures/Lambdas in their languages. This may or may not be high up on the priorities of the Java guys but they have asked for community involvement so I would suggest that those interested in alternative languages for the JVM get involved and lobby for their interests. John Wilson -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
