Tabulators -- a catalog

[Brian Goetz]

The framework ensures that instances of the mutable objects are not 
shared while the operation is in place, so this collapses to the same 
old non-interference requirement as we place on mutable sources like 
ArrayList.

There are lots of things in Java where the only efficient way to do 
something is mutation.  String concat is an example.  We could do a 
functional reduce with String::concat, but it would suck:

   strings.reduce("", String::concat)  // O(n^2) !

We can do a mutable reduce, *safely*, with:

   strings.reduce(StringBuilder::new,
                  StringBuilder::add, StringBuilder::add)

and get much nicer behavior.

Encouraging users to use parallel forEach loops is far more likely to 
result in races/inefficiency than mutable reduction!

And in this particular case, string concatenation must respect order 
(String.concat is associative but not commutative) making parallel 
forEach the wrong tool.  This is naturally a reduction.


On 12/28/2012 3:14 PM, Doug Lea wrote:
> On 12/27/12 21:23, Brian Goetz wrote:
>> Here's a catalog of the currently implemented Tabulators.
>
> Sorry for the protracted grumpiness about Reducers/Tabulators,
> but even if I ignore my other reservations, MutableReduce
> remains the  which-one-doesn't-belong here-winner. Between all
> the concerns about making racy/concurrent mutability too
> easy to do by mistake, and the fact that the implementations
> should be at least as easy for users to code directly using seq/par
> forEach loops, I don't see the story  behind this?
>
> -Doug
>