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