Tabulators, reducers, etc

[Brian Goetz]

Good idea, I'll try to write some of those up tomorrow.

On 12/27/2012 6:50 PM, Sam Pullara wrote:
> 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
> <mailto: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.)
>