toMap options
Brian Goetz
brian.goetz at oracle.com
Tue Apr 9 14:29:21 PDT 2013
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