Into (original) (raw)

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-experts mailing list