Tabulators, reducers, etc

[Sam Pullara]

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
.

Sam

On Thu, Dec 27, 2012 at 10:31 AM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
> 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.)
>