Survey on map/flatMap disambiguation

[Remi Forax]

On 03/22/2013 07:14 PM, Brian Goetz wrote:
> 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.

As Joe said, filter/map/reduce are common concepts,
we should keep them simple.

flatMap doesn't fall in that category so adding several overloads to 
help the compiler
is just something necessary not something which is a design that we 
should apply
on map.

please, we should try to keep the common operation simple if we can.

Rémi

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