Tabulators, reducers, etc

Brian Goetz brian.goetz at oracle.com
Mon Dec 31 10:08:45 PST 2012


> 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.

While the concurrent use case is clearly the odd man out here -- 
suggesting more work is left to do on this -- the rest of it seems an 
improvement on what we have now.  I would like to move forward with this 
while we continue to work out the correct set of canned accumulators and 
the correct way to surface concurrent accumulation.


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