foreach/filter/map/reduce on Iterable & Iterators

[Colin Decker]

The variance of the parameters for most of these methods needs to be
changed. For example, filter should take Predicate<? super T> and map should
take Mapper<? super T, U>.

-- 
Colin


On Wed, Sep 14, 2011 at 9:22 PM, Mike Duigou <mike.duigou at oracle.com> 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
>
>