mergers

[Brian Goetz]

I am OK with using method refs instead of function-returning methods. 
But I think key is that "merge" needs to appear in the name, because, 
while a function that returns the first of its arguments is useful, the 
key here is that we're trying to identify a set of reasonable merging 
policies that are useful when doing "dump a stream into a map".  I think 
even these three simple ones will greatly reduce people's need to write 
mergers themselves for toMap.

Having them live in some place more Mappy would be fine too, but I don't 
want to create a Maps class for them.  Are they important enough to be 
static methods on Map?  (I doubt it.)  So it mostly seems like they're 
in the "desirable to have, but not a great place to shove them" place 
now.  Is Collectors good enough, or do we have to think harder about 
making a better place?

On 4/18/2013 4:35 AM, Paul Sandoz wrote:
>
> On Apr 18, 2013, at 3:21 AM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
>
>> Collectors defines three merge functions:
>>
>>   throwingMerger -- always throws
>>   firstWinsMerger -- takes first
>>   lastWinsMerger -- takes last
>>
>> These are plain old BinaryOperators that can be used for Map.merge as well as the toMap collectors.
>>
>> Someone commented that these look a little out of place in Collectors, and they are certainly not Collector-specific.  Is there a better place for them?
>>
>
> Someone also commented (separately from a survey) that  method refs could be used instead? e.g. like using Integer::sum.
>
> e.g. Objects::first, Objects::second, Objects:throwing
>
> But i thought that might make it harder to correlate with map merging.
>
> They tend to read well when used with toMap code, but perhaps make more sense as static methods on Map due to Map.merge being present?
>
> Paul.
>
>
>