Primitive streams

[Doug Lea]

On 12/28/12 12:55, Brian Goetz wrote:

> It is possible to mitigate this somewhat by having fused mapReduce methods,
> which we tried early on, such as :
>
>    foos.mapReduce(Foo::getWeight, 0, Integer::sum)
>
> Here, at least now all the reduction is happening in the unboxed domain.  But
> the API is now nastier, and while the above is readable, it gets worse in less
> trivial examples where there are more mapper and reducer lambdas being passed as
> arguments and its not obvious which is which. Plus the explosion of mapReduce
> forms: { Obj,int,long,double } x { reduce forms }.  Plus the combination of map,
> reduce, and fused mapReduce leaves users wondering when they should do which.
> All to work around boxing.

Unsurprisingly (since this is what I rely on in CHM :-), I still
think that the stream API need/should not intermix function-composition
and aggregate computation. It is sometimes a bit more appealing, but
not enough to mangle design for. A small cascade of filter-map-reduce
handles all one-pass computations, so long as people use
s.filter(and(p1, p2)) rather than s.filter(p1).filter(p2).
And so on for map, reduce.

-Doug