Updated State of the Collections

[Brian Goetz]

> But I see why they didn't write flatMap that way.  In my example, I have
> author.getBooks() which returns a collection.  If I didn't have a method
> like that, or I didn't want to create a throwaway collection just to hold
> each author's books (which will all then get merged into one collection),
> then if they only gave me a flatMap(A -> Collection<B>) method I'd be
> hosed.  The fact that they give me the sink lets me pick and choose the
> elements in the result individually from wherever I want.

Exactly right.  Not only is it extra work to create a throwaway 
collection (and its extra code in the lambda too, too -- try it), its 
also extra work for the library to iterate it on the other side.  This 
overhead is at its worst when most elements map to zero or one elements 
(like a filter), where you're doing work to create and iterate an empty 
collection.

We've received the feedback that this API is confusing from many people 
are are looking into it.  Havnig a "convenience" version that lets you 
just provide a collection (if you've already got one lying around, as 
you did with author.getBooks()) would probably help.  But, if we had to 
pick one primitive, the one we've got completely dominates the "map to 
collection" version because collections are too heavyweight.