Survey on map/flatMap disambiguation

[Joe Bowbeer]

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/b6276118/attachment-0001.html