kevinb at google.com
Mon Feb 11 08:55:06 PST 2013
+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
> 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
More information about the lambda-libs-spec-observers