Accessing non-final local variables from a lambda expression

[Reinier Zwitserloot]

Nah; I avoid @SuppressWarnings as much as I can. I'd gladly rewrite to
AtomicBoolean even if nothing concurrent is happening to avoid it. More to
the point, I notice this behaviour in almost every other codebase I see, so
it seems to be a bad idea to basically force folks to write copious amounts
of @SuppressWarnings to (warning/error-free) use heap-hosted local
variables. Pragmatically speaking, if this kind of construct is common
enough, then a "nonfinal" or similar explicit "please allocate me on the
heap" keyword would be good. If it's not very common, AtomicX will do.

--Reinier Zwitserloot



On Fri, Feb 26, 2010 at 4:14 PM, Jesse Kuhnert <jkuhnert at gmail.com> wrote:

> Only if you're filtering concurrently.
>
> You sound very sure of your opinions given that the intention is to
> make it as "usable" and safe as possible for the general developer.
> It's a new feature! Why is it so hard to introduce it properly without
> crippling it from the beginning?
>
> On Fri, Feb 26, 2010 at 8:26 AM, Reinier Zwitserloot
> <reinier at zwitserloot.com> wrote:
> <snipped>
> >
> > <T> Iterable<T> everyOther(Iterable<T> input) {
> >   @SuppressWarnings("heapallocation")
> >   boolean flag = true;
> >   return filter(input, (T t) (flag ^= true));
> > }
> >
> > That's clearly inferior to the previous choice, and in my book still
> > inferior to the AtomicBoolean solution.
> >
> > --Reinier Zwitserloot
> >
> >
> >
> > On Fri, Feb 26, 2010 at 9:44 AM, Rémi Forax <forax at univ-mlv.fr> wrote:
> >
> >> Le 26/02/2010 09:23, Lawrence Kesteloot a écrit :
> >> >> In BGGA, CfJ, and other languages with lambdas, one could write it
> >> >> simply like this
> >> >>
> >> >> <T>  Iterable<T>  everyOther(Iterable<T>  input) {
> >> >>     boolean flag = true;
> >> >>     return filter(input, (T t)->(flag ^= true));
> >> >> }
> >> >>
> >> >> But project lambda forbids access to mutable local variables from the
> >> >> enclosing scope.
> >> >>
> >> > <T>  Iterable<T>  everyOther(Iterable<T>  input) {
> >> >     final boolean[] flag = new boolean[] { true };
> >> >     return filter(input, (T t)->(flag[0] ^= true));
> >> > }
> >> >
> >> > It's not beautiful, but not the end of the world either. And the
> >> > performance is comparable, since in any case you have to create and
> >> > dereference some heap object.
> >> >
> >>
> >> +1
> >>
> >> > Lawrence
> >>
> >> Rémi
> >>
> >>
> >
> >
>