Accessing non-final local variables from a lambda expression

[Rémi Forax]

Le 27/02/2010 00:41, Neal Gafter a écrit :
> On Fri, Feb 26, 2010 at 2:59 PM, John Nilsson<john at milsson.nu>  wrote:
>    
>> 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));
>> }
>>      
> Very clever.
>
>    
>> 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?
>>      
> Where it's practical, yes.  But there is a difference between
> encouraging a functional style and discouraging an imperative style.
> I admire the solution, but it isn't realistic to expect people to come
> up with it without significantly more time invested than is required
> for the simple solution.  Most programmers have a job to do and a life
> outside work.
>    

I don't agree, filter and map are simple concepts already
used in several other mainstream languages.

If you have them in java.util, people will use them.

The problem is not to discouraging imperative style
but encourage the developers to use the right tools
for the right problem.
If you want to create (virtually) an iterable from an
iterable, a function style programming is better
than an imperative one.

Rémi