Into
Doug Lea
dl at cs.oswego.edu
Wed Dec 26 07:40:39 PST 2012
On 12/26/12 10:23, Remi Forax wrote:
> that's why we need two different stream ops,
> toList/toSet should conserve the property of the source i.e. create the 'right'
> Set or List implementation depending on the source property and into that uses
> the destination property.
>
> The second problem is what is the interface of a stream which is split to be
> computed in parallel in order to be gathered without using an intermediary data
> structure as now. For toList/toSet, because the pipeline implementation control
> the Set/List implementation, so there is no need of such interface, for into(),
> the question is is with interface pull it's own weight or not ?
>
Right. My line of thought was: We'll need/want the to-* versions
anyway. Given this, do the Reducers/Tabulators pull their weight?
People can always define such things themselves layered on top
of stream API.
While I'm at it, here's a fleshed out version of one possible
to-* API. (Note: under this scheme methods sorted() and unique() go away).
Object[] toArray();
Set<T> toSet();
List<T> toList();
List<T> toRandomAccessList();
List<T> toSortedList(Comparator<? super T> comparator);
List<T> toSortedList();
NavigableSet<T> toSortedSet();
NavigableSet<T> toSortedSet(Comparator<? super T> comparator);
Collection<T> toBag(); // unordered, possible dups
<K> Map<K,T> toMap(Function<? super T,K> keyFn, BinaryOperator<T> mergeFn);
<K> Map<K,<Collection<T>> toMap(Function<? super T,K> keyFn);
<K> NavigableMap<K,T> toSortedMap(Function<? super T,K> keyFn,
Comparator<? super K> comparator,
BinaryOperator<T> mergeFn);
<K> NavigableMap<K,Collection<T>> toSortedMap(Function<? super T,K> keyFn,
Comparator<? super K>
comparator);
More information about the lambda-libs-spec-observers
mailing list