mergers

[Paul Sandoz]

On Apr 18, 2013, at 7:40 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> 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?
> 

My inclination is Collectors is OK since those methods are designed to be closely associated with Collectors.toMap.

FWIW i think it is also possible to offset some of the need for "merge" name with some documentation in Collectors.toMap, however i still like the way it reads in code when those methods are used.

Paul.

> 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.
>> 
>> 
>>