Primitive streams (original) (raw)

Doug Lea dl at cs.oswego.edu
Fri Dec 28 11:39:42 PST 2012

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

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