Accessing non-final local variables from a lambda expression

John Nilsson john at milsson.nu
Fri Feb 26 14:59:25 PST 2010


On Fri, Feb 26, 2010 at 8:36 AM, Neal Gafter <neal at gafter.com> wrote:

> <T> Iterable<T> everyOther(Iterable<T> input) {
>    class Alternator {
>        boolean flag = true;
>        boolean invoke() {
>            return (flag ^= true);
>        }
>    }
>    final Alternator alternate = new Alternator();
>    return filter(input, #(T t)(alternate.invoke());
> }
>

Why not something like this instead?

<T> Iterable<T> everyOther(Iterable<T> input) {
    return zipWithIndex(input).filter(#(long i, T t)(i%2==0)).map(#(long i,
T t)(t));
}

Point being, wouldn't it be better, from a concurrency point of view, to
encourage a functional style of programming instead of focusing on
supporting shared mutable state?

BR,
John


More information about the lambda-dev mailing list