toMap options

Brian Goetz brian.goetz at oracle.com
Tue Apr 9 16:33:45 PDT 2013


I'm good with #3.  Any objections?

On 4/9/2013 7:28 PM, Sam Pullara wrote:
> I like version 3 as well.
>
> Sam
>
> On Apr 9, 2013, at 2:29 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> Currently we have:
>>
>>     Collector<T, Map<T,U>>
>>     toMap(Function<? super T, ? extends U> mapper)
>>
>> and
>>
>>     <T, U, M extends Map<T, U>>
>>     Collector<T, M>
>>     toMap(Function<? super T, ? extends U> mapper,
>>           Supplier<M> mapSupplier,
>>           BinaryOperator<U> mergeFunction)
>>
>> (plus concurrent versions of both of these.)  The former is just sugar for:
>>
>>   toMap(mapper, HashMap::new, throwingMerger())
>>
>> (We have predefined merge functions for throw-on-duplicates, first-wins, and last-wins, called throwingMerger, firstWinsMerger, and lastWinsMerger.)
>>
>> As has been noted, we do not yet serve the use case of creating a map where the stream elements are the values of the map instead of the keys of the map.  Options for addressing this are:
>>
>> 1.  Leave toMap as is, add toIndexedMap (or toKeyedMap) variants.
>>
>> 2.  Leave toMap as is, add a two-function version of toMap:
>>
>>     <T,K,U>
>>     Collector<T, Map<K,U>>
>>     toMap(Function<T, K> keyMapper,
>>           Function<T, U> valueMapper)
>>
>> in which case the regular toMap becomes sugar for
>>
>>     toMap(Function.identity(), mapper)
>>
>> 3.  Get rid of the current form of toMap, and just have the two-function form as in (2).
>>
>> 4.  Break free of the toMap naming (recall that until recently this was called mappedTo, and prior to that, joiningWith), and have two versions: mappedTo and mappedFrom.  This is explicit, but also doesn't address the use case where both key and value are functions of the stream elements.
>>
>> Others?
>>
>


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