Reducing reduce

[Kevin Bourrillion]

+1, please drop it.


On Mon, Feb 11, 2013 at 8:41 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> Now that we've added all the shapes of map() to Stream (map to
> ref/int/long/double), and we've separated functional reduce (currently
> called reduce) from mutable reduce (currently called collect), I think that
> leaves room for taking out one of the reduce methods from Stream:
>
>     <U> U reduce(U identity,
>                  BiFunction<U, ? super T, U> accumulator,
>                  BinaryOperator<U> reducer);
>
> This is the one that confuses everyone anyway, and I don't think we need
> it any more.
>
> The argument for having this form instead of discrete map+reduce are:
>  - fused map+reduce reduces boxing
>  - this three-arg form can also fold filtering into the accumulation
>
> However, since we now have primitive-bearing map methods, and we can do
> filtering before and after the map, is this form really carrying its
> weight?  Specifically because people find it counterintuitive, we should
> consider dropping it and guiding people towards map+reduce.
>
> For example, "sum of pages" over a stream of Documents is better written
> as:
>
>   docs.map(Document::**getPageCount).sum()
>
> rather than
>
>   docs.reduce(0, (count, d) -> count + d.getPageCount(), Integer::sum)
>
> The big place where we need three-arg reduce is when we're folding into a
> mutable store.  But that's now handled by collect().
>
> Have I missed any use cases that would justify keeping this form?
>
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130211/17401f11/attachment.html