Iterable::forEach not returning Iterable

Rémi Forax forax at univ-mlv.fr
Thu May 17 07:31:40 PDT 2012


On 05/17/2012 04:05 PM, Brian Goetz wrote:
> Of course, no one would write production code like this.  Mappers are 
> supposed to be side-effect-free.  But it is an acceptable sin for 
> temporary debugging code.

Haskell guys, please don't read ...

but logging is side effect free until you read the log in the program.

Rémi

>
> On 5/17/2012 9:26 AM, Remi Forax wrote:
>> You can use
>>    map(it ->  {
>>       Log.log(it);
>>       return it;
>>     }).
>> instead of forEach.
>>
>> Rémi
>>
>> Sent from my Phone
>>
>> ----- Reply message -----
>> From: "Tomasz Kowalczewski"<tomasz.kowalczewski at gmail.com>
>> To: "lambda-dev"<lambda-dev at openjdk.java.net>
>> Subject: Iterable::forEach not returning Iterable
>> Date: Thu, May 17, 2012 12:33
>>
>>
>> Hi,
>>
>> I was trying out the new jdk8 build with lambdas and while doing some
>> simple towards-lamda-refactoring I stumbled on following use case:
>>
>> List<File>  files...
>> files.filter( File::isFile ).filter( ... ).map( 
>> ConfigurationFile::new );
>>
>> I wanted to inject some debugging code inside this chain using forEach
>> and realized that it returns void and not Iterable. Its default
>> delegates to Iterables::forEach that returns Interable, so I guess it
>> is just a matter of deciding if forEach should seal the pipe or allow
>> more processing.
>>
>> Based on my example I think there is a great value in changing the
>> return type from void as in my opinion it will be harder to debug and
>> step through such lambdanized code than through several (ugly)
>> for-each loops doing same work.
>>
>> P.S.: Atttaching eclipse debugger to this code being run in a simple
>> main() instantly crashes the debugged JVM. But I guess debugging is
>> not yet supported anyway :)
>>



More information about the lambda-dev mailing list