toMap options

[Tim Peierls]

No objection, but now it makes me wonder: How do you get the effect of
toMultimap(T->K, T->V)? In other words, how would you get a Map<K,
Collection<V>> from a Stream<T> given T->K and T->V mappings?

--tim

On Tue, Apr 9, 2013 at 7:33 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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?
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130409/ef58bf78/attachment-0001.html