Survey on map/flatMap disambiguation

[Brian Goetz]

Thanks for writing up your concerns all in one place.

> 1. Performance gotchas?

Of these, I think this is the worst of the concerns.  However, I also 
think its not as bad as it sounds.  When a user hits ctrl-space in the 
IDE, they'll see (close to each other) all the mapToXxx forms, which has 
actually a lot of educational value.  [1]

Secondly, while boxed performance is definitely much worse than 
non-boxed, for small streams (and most collections are small), it might 
not make a difference anyway.  I've definitely had the experience many 
many times of discovering "egregious" performance "bugs" like this that 
turned out to have no effect on actual business-relevant performance 
metrics, because all the cost was in the { XML parsing, database access, 
network latency, crypto, etc }.  For those cases where it does make a 
difference, profiling will disclose this immediately.  So its a gotcha, 
but not a disaster.

So I think its a gotcha but nothing so bad that this makes the 
difference for me.

> 2. Consistency.  What about other similar methods?
>
> My main concern is that this change will (or should?) cascade to other
> methods, and, in the end, a patch that need only be applied to flatMap
> ripples through the entire API.

I did a quick look and didn't see any other obvious examples of this 
pattern, where we've overloaded methods for all the X-to-Y stream 
conversions.  Did you find any ripples I missed?

> 3. Breaks map/reduce functional feel?
>
> The other concern that I stated previously is that this mars the
> familiar map/reduce functional feel, without helping enough with the
> usability or readability.  Either way, an IDE will be indispensable.

This is obviously subjective but for me it felt OK.



[1] Educating people that there are multiple stream shapes, whose 
methods are similar but not exactly the same, is important.  Calling all 
the methods "map" may make people believe that there's a sum() method on 
Stream, and be surprised when there is not.  But .mapToInt(...).sum() 
makes it more obvious what is going on here, which is arguably a plus.