Survey on map/flatMap disambiguation

[Joe Bowbeer]

The proposed changes, for review, are:

 Stream.map -> {map,mapTo{Int,Long,Double}}
 Stream.flatMap -> {flatMap,flatMapTo{Int,Long,**Double}}
 {Int,Long,Double}Stream.map -> map,mapToObj

I think there are several points worth discussing:

1. Performance gotchas?

The performance gotcha that Brian mentioned in his followup:

This does create a possibility for performance bugs, where users do:
>   stuff.map(Foo::size).reduce(0, Integer::sum)
> instead of
>   stuff.mapToInt(Foo::size).**reduce(0, Integer::sum)
> Both will now compile, but the former will be boxed and the latter won't
> be.  The previous status quo saved users from themselves in this case.


Does this change anyone's mind?

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.

In offline correspondence, Brian writes:

The "could use the wrong map" case is ugly, but then again so is having to
> cast if you really wanted the boxed version.  Over time we've been moving
> in the direction of "less overloading when lambdas are involved", and the
> move to more explicit names makes sense there (maybe there are others too
> we should consider?)  In hindsight, this ought to have been obvious (type
> inference and same-arity-overloading always fight with each other.)


Are there other cases that we should consider?  If so, I suggest we
consider them now before extending this merely to the map case.

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.

Joe


On Mon, Mar 18, 2013 at 7:27 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> It seems there were some second thoughts on this after the survey.  I'll
> wait another 24 hours for discussion to take root, otherwise I'll push the
> change.
>
>
> On 3/14/2013 1:04 PM, Brian Goetz wrote:
>
>> The survey is closed, results are here:
>>
>> https://www.surveymonkey.com/**sr.aspx?sm=**
>> 9UyN8RRvMX8BnpTdd4rYgDlXU9uUVA**LNDjNn_2fY2e9_2fo_3d<https://www.surveymonkey.com/sr.aspx?sm=9UyN8RRvMX8BnpTdd4rYgDlXU9uUVALNDjNn_2fY2e9_2fo_3d>
>>
>>
>> The sense of the EG was strongly in favor of disambiguating both map and
>> flatMap; several argued that they liked the "less magic" aspect of it,
>> and the explicitness of where we go from reference to primitive streams
>> and back.
>>
>> This does create a possibility for performance bugs, where users do:
>>
>>    stuff.map(Foo::size).reduce(0, Integer::sum)
>>
>> instead of
>>
>>    stuff.mapToInt(Foo::size).**reduce(0, Integer::sum)
>>
>> Both will now compile, but the former will be boxed and the latter won't
>> be.  The previous status quo saved users from themselves in this case.
>>
>> Will make the following changes:
>>
>>   Stream.map -> {map,mapTo{Int,Long,Double}}
>>   Stream.flatMap -> {flatMap,flatMapTo{Int,Long,**Double}}
>>   {Int,Long,Double}Stream.map -> map,mapToObj
>>
>>
>> On 3/10/2013 7:51 PM, Brian Goetz wrote:
>>
>>> I've posted a survey for the EG at:
>>>
>>>    https://www.surveymonkey.com/**s/NT5DW7G<https://www.surveymonkey.com/s/NT5DW7G>
>>>
>>> where people can express their opinion on the issue of flatMap
>>> disambiguation (see thread entitled "flatMap ambiguity").
>>>
>>> The password has been communicated directly to the EG; contact me if you
>>> didn't get it.
>>>
>>> Usual survey rules: enter your name with your response, all results will
>>> be made public after the survey closes.  I'll set a closing time of 6PM
>>> PT Wednesday of this week.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130319/50afe8ba/attachment.html