Accessing non-final local variables from a lambda expression

[Jesse Kuhnert]

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
>>
>>
>
>