Tabulators, reducers, etc (original) (raw)

Sam Pullara sam at sampullara.com
Thu Dec 27 15:50:28 PST 2012

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 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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121227/58587af2/attachment.html

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