Survey on map/flatMap disambiguation

[Sam Pullara]

I'm for putting in the mapToInt etc. Anything to stop type inference from slowing me down. Most of the issues I run into when building things are mismatches between various overloads.

Sam

On Mar 22, 2013, at 1:39 PM, Remi Forax <forax at univ-mlv.fr> wrote:

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