Effectively final

[Tim Fox]

On 30/07/2011 14:18, Rémi Forax wrote:
> On 07/30/2011 11:32 AM, Tim Fox wrote:
>> Consider another example written in Ruby:
>>
>> def foo(socket)
>>      timed_out = false
>>      system.set_timeout(100) { timed_out = true }
>>      socket.on_data{ puts "Got data" if !timed_out}
>> end
>>
>> This case would be overkill to use your technique in Java (an
>> AtomicBoolean would do), but then I have to explain to the user why they
>> have to use an AtomicBoolean when there's only one thread executing it:(
> Java 8 is more verbose, but not much:
>
> void foo(AsyncSocket socket) {
>     int[] timeout = {false };
>     AsyncSystem.setTimeout(100, #{ timeout[0] = true; });
>     socket.onData(#{ socket ->  if (!timeout[0]) socket.write("Got data");
> });
> }
I would consider the use of an array like that as ugly cruft. And even 
worse, if this was multi-threaded (which thankfully it isn't) it would 
still be subject to race conditions, which goes to show that requiring 
final locals in closures doesn't actually protect you from races since 
you can do ugly workarounds like this (or just use some final ref to an 
arbitrary object) ;)
>
> BTW, why your framework doesn't manage the timeout by itself
> instead of letting the users create bad and sluggish webserver because
> they forget to set a timeout.
That snippet was nothing to do with a web server. It was just a 
contrived example using timeout. Most eventing systems allow users to 
set arbitrary timeouts, that can do anything they want.
>
> Rémi
>
>