Tabulators, reducers, etc (original) (raw)

Brian Goetz brian.goetz at oracle.com
Thu Dec 27 15:57:52 PST 2012

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 reducer); Optional reduce(BinaryOperator reducer); U reduce(U zero, BiFunction<U, T, U> accumulator, BinaryOperator reducer); R accumulate(Accumulator<T, R> reducer); R accumulate(Supplier seedFactory, BiBlock<R, T> accumulator, BiBlock<R, R> reducer); _ 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.)

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