toMap options

[Sam Pullara]

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