flatMap signature (original) (raw)

Zhong Yu zhong.j.yu at gmail.com
Tue Apr 2 08:27:39 PDT 2013

On Tue, Apr 2, 2013 at 7:51 AM, Remi Forax <forax at univ-mlv.fr> wrote:

On 04/02/2013 02:44 PM, Boaz Nahum wrote: > Stream: > ----------------------------------------------------------------------------------------------------------- > As Brian correct me: > Stream flatMap(Function<? super T, ? extends Stream<? extends R>> > mapper); > > instead of: > Stream flatMap(Function<T, Stream<? extends R>> mapper); > > ----------------------------------------------------------------------------------------------------------- > T reduce(T identity, BinaryOperator accumulator); > and > Optional reduce(BinaryOperator accumulator); > > Can't be fixed because they used 'BinaryOperator', But if 'BiFunction' is > used then we have more flexibility > ------------------------------------------------------------------------------------------------------------ > U reduce(U identity, > BiFunction<? super U, ? super T, ? extends U> > accumulator, > BinaryOperator combiner) > > Instead of: > > U reduce(U identity, > BiFunction<U, ? super T, U> accumulator, > BinaryOperator combiner); > > Same comment regarding 'BinaryOperator' > > ------------------------------------------------------------------------------------------------------------ > R collect(Supplier resultFactory, > BiConsumer<? super R, ? super T> accumulator, > BiConsumer<? super R, ? super R> combiner) > > Instead of: > > R collect(Supplier resultFactory, > BiConsumer<R, ? super T> accumulator, > BiConsumer<R, R> combiner); > > > I tested all my suggestions with examples and pseudo implementation, > example: > > default U reduce(U identity, > BiFunction<? super U, ? super T, ? extends U> > accumulator, > BinaryOperator combiner) { > > Collection this = .... > > U result = identity; > > for (T element : this) > result = accumulator.apply(result, element); > > return combiner.apply(identity, result); > > } > > If you find my comments useful, I will be more than glad to continue on > other API.

It's very useful. I don't want to forget one wildcard,

(any plan to do something about wildcards? java 9? 10?)

so several eyeballs are better than just mine.

BinaryOperator will not be replaced by BiFunction even if, as you said, it introduce more flexibility, a BinaryOperator ask that the two parameters and the return type to be the same so it has conceptually more weight (the EG already votes on that). I also think that all Supplier should be Supplier<? extends T>. Rémi > > > > On Mon, Apr 1, 2013 at 1:32 PM, Remi Forax <forax at univ-mlv.fr> wrote: > >> On 03/31/2013 05:10 PM, Boaz Nahum wrote: >>> I have some problems when compiling with flatMap, >>> >>> Maybe the signature should be: >>> >>> Stream flatMap(Function<? super T, Stream<? extends R>> mapper); >>> >>> Instead of: >>> >>> Stream flatMap(Function<T, Stream<? extends R>> mapper); >>> >> yes, probably, >> I will do a pass on the whole API to fix all wildcards, >> if you or anybody on this list want to help me, >> it would be great. >> >> cheers, >> Rémi >> >> >>

More information about the lambda-dev mailing list