Forms for reduce() -- part 1 (original) (raw)

Brian Goetz brian.goetz at oracle.com
Fri Dec 14 12:15:16 PST 2012

Open question: do we keep the name mutableReduce to make it clear what is going on? If you went without the name, I'm not sure how clear it will be with the existing types that one is mutating or non mutating. Would this make sense, or not so much? U reduce(U zero, BiFunction<U, T, U> nonMutatingAccumulator, BinaryOperator nonMutatingReducer); R reduce(Supplier seedFactory, BiBlock<R, T> mutatingAccumulator, BiBlock<R, R> mutatingReducer);

There's no reason this doesn't work. My concern was that calls of both will involve lambdas of two arguments, and it will be less obvious by reading the code whether (a, b) -> goo is being used as a functional reducer or a mutable accumulator. The parameter names will not be present at the use site, so readers of the code will have to reason about whether this is a functional reduce or a mutable inject.

So, the question remains -- is the word "mutable" (or some other way of saying that) a helpful guide about what is being done here, or pedantic noise that will irritate the users? (Note that I think we should care much less how it makes people feel when writing code than how it helps comprehension when reading code.)

These are APIs we've had in a separate library for several years that we've moved into GS Collections RichIterable interface and which will become available in our 3.0 release. They are a combination of groupBy/injectInto so certainly have some differences to reduce, but they also have some similarities in terms of supporting mutating/non-mutating versions. We chose not to go with the name mutableAggregateBy, but instead named the parameter mutatingAggregator or nonMutatingAggregator. We felt the difference in type made it pretty clear (Function2 vs. Procedure2).

The type does make it clear when the call site has "new Function() { ... }". Which of course described many call sites in a pre-lambda world. In a post-lambda world, the type is inferred, and both functions and blocks often look similar at the use site:

(a, b) -> a+b (a, b) -> a.add(b) // where add(b) is void-bearing and mutative

More information about the lambda-libs-spec-experts mailing list