Survey on map/flatMap disambiguation

Brian Goetz brian.goetz at
Fri Mar 22 11:14:05 PDT 2013

There was no further discussion on this thread, so given that there was 
already a poll in favor, and little followup afterwards, I'm inclined to 
push this change.

On 3/19/2013 11:22 AM, Brian Goetz wrote:
> 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.

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