Survey on map/flatMap disambiguation

[Brian Goetz]

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.
>