foreach/filter/map/reduce on Iterable & Iterators

[Colin Decker]

"? extends U" isn't necessary for map. All that allows is assigning what is
really, say, an Iterable<Integer> to Iterable<Number> or Iterable<Object>
without casting, which doesn't help anything.

-- 
Colin


On Wed, Sep 14, 2011 at 11:38 PM, Craig P. Motlin <cmotlin at gmail.com> wrote:

> The generics need to be Mapper<? super T, ? extends U> on all Mapper method
> parameters.
>
>
> On Wed, Sep 14, 2011 at 10:59 PM, Mike Duigou <mike.duigou at oracle.com>wrote:
>
>> Yes I agree this should be done.
>>
>> On the other hand, is it reasonable to expect that most lambdas will be
>> specified as SAM conversions which will make the "? super" unnecessary? Are
>> there specific practical cases where we expect lambdas to be used that will
>> require the "? super" in order to be accepted? Where will those lambdas be
>> coming from?
>>
>> Mike
>>
>> On Sep 14 2011, at 19:44 , Colin Decker wrote:
>>
>> > 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
>>
>>
>