Effectively final

[Per Bothner]

On 08/17/2011 01:53 AM, Roel Spilker wrote:
>
>     Put your 2 paragraphs together and you have your answer:  The container
>     object *is* the inner class instance.  The compiler translates both
>     reads and
>     writes of the variable to reads and writes of the field.
>
>
> That won't work since the lifespan of the variable and the closure are
> not the same. So you need a different container.

Assume that the closure only "captures" a single local variable.
In that case the closure has no state *except* that variable,
and the lifetime of the closure is a subset of the lifetime
of the variable.  So there is (as far as I can see) no problem
using a single object that contains both the variable and the
closure (as an inner class instance), and allocating it when
the local variable goes into scope.

If the closure references multiple local variables, no real problem if
they all in the same scope.  Likewise, if there is no loop in between
the variables.  However, if some of the captures variables are external
to a loop and some are internal, then an extra helper object would be 
needed.

Of course this is all academic.  If at some point we add support for
lambdas capturing non-final locals, by that time we may have some
better implementation strategy that doesn't use an inner class at all.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/