Survey on map/flatMap disambiguation

Brian Goetz brian.goetz at oracle.com
Thu Mar 14 12:21:56 PDT 2013


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=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.
>
>
>
>
>     --
>     Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
>     <mailto:kevinb at google.com>
>
>


More information about the lambda-libs-spec-experts mailing list