foreach/filter/map/reduce on Iterable & Iterators

[Rémi Forax]

Hi Mike,

Here is my comments:
   in Iterables, for filter, map and filterMap, you should create one
     class that implements Iterable and store a predicate (or null) and 
a mapper (or null)
     and an Iterable to crawle.
     This class should also override all defender method from Iterable,
     by example, if the mapper is null, if the filter is null and you 
call filter() then you create an new instance
     of that class that just store the filter. if the mapper is null and 
a filter already exist,
     you can combine the existing filter with the new one with and(), etc.
   With this trick we may even don't have to have the fused versions because
   the escape analysis done by the VM will be able to remove the 
intermediary object.

   forEach() should return void and not an Iterable because it's an 
eager operation,
   all lazy operations should return an Iterable, all eager operations 
should return
   the result or void.

    The name intoCollection is too verbose, "into" is in my opinion better.

Rémi


On 09/15/2011 03:22 AM, Mike Duigou wrote:
> I've pushed a change to the lambda dev repo which introduces forEach/filter/map/reduce (as well as fused versions such as "filterMapReduce") on the Iterable interface. In addition it currently adds isEmpty() and intoCollection(). We're still evaluating whether these last two are sufficiently useful to warrant inclusion.
>
> The implementation of forEach/filter/map/reduce for Iterable is provided via defaulted extension methods with the implementations residing in Iterables [name subject to change]. The implementations are a mix of eager and lazy and none make assumptions about concurrency capabilities (or lack thereof) of the source collections. The forEach(), reduce() and intoCollection() are all eager--they complete all work before returning. map() and filter() are lazy--they process elements as they are read from the result Iterable. Some of the behaviour uses the Iterators class.
>
> Iterators contains implementations of forEach/filter/map/reduce which work upon Iterators. The lazy/eager semantics are the same as the Iterables implementations. These methods are currently not provided as defenders upon Iterator, but they could be. From the limited discussion thus far it seems that having forEach/filter/map/reduce on Iterator will be used less commonly than on Iterable. For the cases where only an Iterator is available the static methods in Iterators can still be called.
>
> Very basic unit tests are also provided.
>
> Mike
>