Survey on map/flatMap disambiguation

[Joe Bowbeer]

Actually, what I'd need is a reduceFromObj, not mapToObj.

Either way, I think this change needs to be seen in the context of sample
code.

The survey describes the benefits from one point of view, but leaves out
some important details, and omits a gnarly issue.  As a result, I think
you're reading too much into these comments.  (Are they really independent
verification? Or merely a rephrasing of the proposed benefits?)

>From my point of view, it's important that the terms 'map' and 'reduce'
remain constant.  This gives the code a familiar functional look.
 Unfortunately, it is a problem trying to read code that changes between
int and Obj streams, but I'm not convinced that these extra characters in
the method names are going to help much.  I think an IDE will
be indispensable either way.

Joe


On Thu, Mar 14, 2013 at 12:31 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> Does the use of mapToObj() allow a boxed() to be removed?  That could be a
> feature.
>
>
>
> On Thu, Mar 14, 2013 at 12:21 PM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
>> Right.  For the primitive streams, I applied the "add a suffix if you are
>> changing types", so IntStream.map() is for int->int, and mapToObj() is for
>> int->Object.
>>
>> What compelled me about the results of this survey is that multiple
>> people explicitly called out that they liked the mapToXxx not for
>> consistency, but for the explicitness of it.  Because the types are lost to
>> method chaining, .mapToInt() carries a lot of information about the fact
>> that there's a type switcheroo going on.  Whereas overloaded map() is magic.
>>
>>
>> On 3/14/2013 3:11 PM, Joe Bowbeer wrote:
>>
>>> The survey (and proposal) did not mention the affect on Int/Long/Double
>>> streams either.  mapToInt, mapToObj, map...
>>>
>>> Is this verbose strangeness introduced in the map namespace worth having
>>> consistency with flatMap?  I'd rather sacrifice flatMap than change map.
>>>
>>> I think the results of this survey should be tabled until a complete
>>> proposal is presented.
>>>
>>>
>>>
>>> On Thu, Mar 14, 2013 at 10:26 AM, Kevin Bourrillion <kevinb at google.com
>>> <mailto:kevinb at google.com>> wrote:
>>>
>>>     Ouch.  That is pretty gnarly.  Did we realize that before we voted?
>>>
>>>
>>>
>>>     On Thu, Mar 14, 2013 at 10:04 AM, Brian Goetz
>>>     <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com**>> 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=__9UyN8RRvMX8BnpTdd4rYgDlXU9uUVA__LNDjNn_2fY2e9_2fo_3d>
>>>
>>>         <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>
>>>
>>>             <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.
>>>
>>>
>>>
>>>
>>>     --
>>>     Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
>>>     <mailto:kevinb at google.com>
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130314/183a0bf5/attachment.html