Closures, too much or too little?

[Mark Mahieu]

On 23 Nov 2009, at 19:37, tronicek at fit.cvut.cz wrote:

> 
>> So for me, a more practical variation of "auto-finalization" would be that
>> the variable only 'becomes' final at the point in the code where the
>> closure appears.
> 
> What you mean by "becoming final"? Do you propose to flush all the
> (non-final) variables, which are used in the closure, to the shared memory
> at the point where this closure is declared?

More musing on than proposing, but I'm suggesting that it's common for the local variable to only initially want to be mutable, whilst I'm in the process of setting up its value.  After that's done with, I'd currently need to assign it to a final variable if I want to use its value in an anonymous class, which is annoying, even though (in my 'common' example) I make no attempt to assign to it again in the method, nor in any anonymous class (or closure) that references it.

So I'm wondering whether there's a sensible (and clear) rule which would allow the compiler to do that 'annoying part' for me when necessary, such that:

int count = 0;
count++;    // ok, obviously

// count 'becomes' final about here
Runnable r = #() { doSomethingWith(count); };    // still ok, not trying to assign to it

count++;    // compiler error - "Can't assign to variable 'count' after use in closure blah blah"


It's kinda like the "auto-finalization" that Josh referred to, but deferring the "finalization" part until it's actually needed ('needed' being highly subjective, admittedly).

Dunno.

Mark