(original) (raw)
I really like this suggested API. I think it would be easier to digest with concrete examples that show that these choices are orthogonal and necessary .
One option might be: use "reduce" for the purely functional forms, use accumulate/accumulateConcurrent for the others:
� � T reduce(T zero, BinaryOperator<T> reducer);
� � Optional<T> reduce(BinaryOperator<T> reducer);
� � <U> U reduce(U zero, BiFunction<U, T, U> accumulator, BinaryOperator<U> reducer);
� � <R> R accumulate(Accumulator<T, R> reducer);
� � <R> R accumulate(Supplier<R> seedFactory,
� � � � � � � � � � �BiBlock<R, T> accumulator,
� � � � � � � � � � �BiBlock<R, R> reducer);
� � <R> R accumulateConcurrent(ConcurrentAccumulator<T, R> tabulator);
� This would let us get rid of the Tabulator abstraction (it is identical to MutableReducer; both get renamed to Accumulator). Separately, with a small crowbar, we could simplify ConcurrentAccumulator down to fitting into existing SAMs, and the top-level abstraction could go away.
We would continue to have the same set of combinators for making tabulators, and would likely have concurrent and not flavors for the Map ones (since there's a real choice for the user to make there.)