Hello!
In my StreamEx library I created a "pairing" collector which does similar
job, but allows user to decide how to combine the results of two
collectors. This adds more flexibility. The signature is like this:
public static <T, A1, A2, R1, R2, R> Collector<T, ?, R> pairing(
Collector<? super T, A1, R1> c1,
Collector<? super T, A2, R2> c2,
BiFunction<? super R1, ? super R2, ? extends R> finisher)
Having such collector, The proposed `toBoth(c1, c2)` can be implemented as
simple as `pairing(c1, c2, Map::entry)`. OTOH if somebody wants to use
their own Pair class, it would be `pairing(c1, c2, Pair::new)`.
Sometimes you don't need a pair, but can create compound result object
right here. E.g.:
Collector<BigDecimal, ?, BigDecimal> summing =
Collectors.reducing(BigDecimal.ZERO, BigDecimal::add);
Collector<BigDecimal, ?, BigDecimal> averaging =
pairing(summing, Collectors.counting(), (sum, count) ->
sum.divide(BigDecimal.valueOf(count),
RoundingMode.HALF_EVEN));
So locking to Map.Entry is entirely unnecessary.
With best regards,
Tagir Valeev.
On Thu, Jun 14, 2018 at 6:11 AM Brian Goetz <brian.go...@oracle.com> wrote:
> I really like how BiCollector can be private, so all we'd have to expose
> is toBoth(), and the arguments of toBoth() are just ordinary
> collectors. So no new types or abstractions; just a multiplexing.
>
> The use of Map.Entry as a pair surrogate is unfortunate -- its
> definitely not an Entry -- though I understand why you did this. I'm not
> sure if this is fatal or not for a JDK method, but it's pretty bad*.
> (You could generalize to n-ary, returning a List or array (you can take
> a varargs of Collector), at the loss of sharp types for the results.)
>
>
> *Yes, I'm sure one can find precedent of this being done; this has no
> effect on whether it's bad.
>
> On 6/11/2018 8:39 AM, Peter Levart wrote:
> > Hi,
> >
> > Have you ever wanted to perform a collection of the same Stream into
> > two different targets using two Collectors? Say you wanted to collect
> > Map.Entry elements into two parallel lists, each of them containing
> > keys and values respectively. Or you wanted to collect elements into
> > groups by some key, but also count them at the same time? Currently
> > this is not possible to do with a single Stream. You have to create
> > two identical streams, so you end up passing Supplier<Stream> to other
> > methods instead of bare Stream.
> >
> > I created a little utility Collector implementation that serves the
> > purpose quite well:
> >
> > /**
> > * A {@link Collector} implementation taking two delegate Collector(s)
> > and producing result composed
> > * of two results produced by delegating collectors, wrapped in {@link
> > Map.Entry} object.
> > *
> > * @param <T> the type of elements collected
> > * @param <K> the type of 1st delegate collector collected result
> > * @param <V> tye type of 2nd delegate collector collected result
> > */
> > public class BiCollector<T, K, V> implements Collector<T,
> > Map.Entry<Object, Object>, Map.Entry<K, V>> {
> > private final Collector<T, Object, K> keyCollector;
> > private final Collector<T, Object, V> valCollector;
> >
> > @SuppressWarnings("unchecked")
> > public BiCollector(Collector<T, ?, K> keyCollector, Collector<T,
> > ?, V> valCollector) {
> > this.keyCollector = (Collector)
> > Objects.requireNonNull(keyCollector);
> > this.valCollector = (Collector)
> > Objects.requireNonNull(valCollector);
> > }
> >
> > @Override
> > public Supplier<Map.Entry<Object, Object>> supplier() {
> > Supplier<Object> keySupplier = keyCollector.supplier();
> > Supplier<Object> valSupplier = valCollector.supplier();
> > return () -> new
> > AbstractMap.SimpleImmutableEntry<>(keySupplier.get(), valSupplier.get());
> > }
> >
> > @Override
> > public BiConsumer<Map.Entry<Object, Object>, T> accumulator() {
> > BiConsumer<Object, T> keyAccumulator =
> > keyCollector.accumulator();
> > BiConsumer<Object, T> valAccumulator =
> > valCollector.accumulator();
> > return (accumulation, t) -> {
> > keyAccumulator.accept(accumulation.getKey(), t);
> > valAccumulator.accept(accumulation.getValue(), t);
> > };
> > }
> >
> > @Override
> > public BinaryOperator<Map.Entry<Object, Object>> combiner() {
> > BinaryOperator<Object> keyCombiner = keyCollector.combiner();
> > BinaryOperator<Object> valCombiner = valCollector.combiner();
> > return (accumulation1, accumulation2) -> new
> > AbstractMap.SimpleImmutableEntry<>(
> > keyCombiner.apply(accumulation1.getKey(),
> > accumulation2.getKey()),
> > valCombiner.apply(accumulation1.getValue(),
> > accumulation2.getValue())
> > );
> > }
> >
> > @Override
> > public Function<Map.Entry<Object, Object>, Map.Entry<K, V>>
> > finisher() {
> > Function<Object, K> keyFinisher = keyCollector.finisher();
> > Function<Object, V> valFinisher = valCollector.finisher();
> > return accumulation -> new AbstractMap.SimpleImmutableEntry<>(
> > keyFinisher.apply(accumulation.getKey()),
> > valFinisher.apply(accumulation.getValue())
> > );
> > }
> >
> > @Override
> > public Set<Characteristics> characteristics() {
> > EnumSet<Characteristics> intersection =
> > EnumSet.copyOf(keyCollector.characteristics());
> > intersection.retainAll(valCollector.characteristics());
> > return intersection;
> > }
> > }
> >
> >
> > Do you think this class is general enough to be part of standard
> > Collectors repertoire?
> >
> > For example, accessed via factory method Collectors.toBoth(Collector
> > coll1, Collector coll2), bi-collection could then be coded simply as:
> >
> > Map<String, Integer> map = ...
> >
> > Map.Entry<List<String>, List<Integer>> keys_values =
> > map.entrySet()
> > .stream()
> > .collect(
> > toBoth(
> > mapping(Map.Entry::getKey, toList()),
> > mapping(Map.Entry::getValue, toList())
> > )
> > );
> >
> >
> > Map.Entry<Map<Integer, Long>, Long> histogram_count =
> > ThreadLocalRandom
> > .current()
> > .ints(100, 0, 10)
> > .boxed()
> > .collect(
> > toBoth(
> > groupingBy(Function.identity(), counting()),
> > counting()
> > )
> > );
> >
> >
> > Regards, Peter
> >
>
>
