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