Le 27/11/2009 16:56, [email protected] a écrit :
> 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.
>
In my opinion, what we want is immutability of shared object, not for
all objects,
side effects are Ok if they are sandboxed or if you mutate things
like concurrent collections
About final, final also have an impact on the publication of variables.
If bounded local variables aren't final, there is no guarantee.
int sum = 0;
for(int i=0; i<5; i++) {
final int value = i;
new Thread(#() {
sum + = i;
}).start();
}
The example above is not thread safe and if sum is declared volatile
(I suppose here that this is legal to do that) it is again not thread safe.
>
> Xavier Clerc
>
Rémi Forax
--
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.
