Selon John Wilson <[email protected]>: > 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).
Well, my answer was indeed sarcastic ... The point is that "final" is a qualifier for a reference, while the argument put forward by Remi Forax would hold if the qualifier guaranteed that the value referenced is "immutable" (counterexample: a "final" array is clearly mutable). When playing with multicores, it seems that the properties that you are interested in are related to immutability, and moreover to the absence of side-effects at large. A guarantee that coincide for sure with "finality" only for primitives types. Hence the irony of my answer. Xavier Clerc -- 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.
