BiCollector

[Jacob Glickman]

Agreed.  Not sure if this has been suggested, but what about duplex(ing)?

On Mon, Jun 18, 2018 at 5:29 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> "bisecting" sounds like it sends half the elements to one collector and
> half to the other ...
>
> "tee" might be a candidate, though it doesn't follow the `ing
> convention.  "teeing" sounds dumb.
>
>
>
> On 6/15/2018 7:36 PM, Paul Sandoz wrote:
> > Hi Tagir,
> >
> > This is looking good.
> >
> > My current favorite name for the factory method is “bisecting” since we
> are dividing the collector into two collectors, the results of which are
> then merged.
> >
> > Suggested first paragraph of the factory method:
> >
> >    "Returns a collector that passes the input elements to two specified
> collectors and merges their results with the specified merge function.”
> >
> > Paul.
> >
> >
> >> On Jun 15, 2018, at 4:26 AM, Tagir Valeev <amaembo at gmail.com> wrote:
> >>
> >> Hello!
> >>
> >> I created a preliminary webrev of my own implementation (no testcases
> yet):
> >> http://cr.openjdk.java.net/~tvaleev/patches/pairing/webrev/
> >> If anybody wants to sponsor my implementation, I will happily log an
> issue and write tests.
> >>
> >> The name "pairing" was invented by me, but as I'm not a native English
> speaker I cannot judge whether it's optimal, so better ideas are welcome.
> >> Also I decided to remove accumulator types from public type variables.
> They do not add anything to type signature, only clutter it
> >> increasing the number of type parameters from 4 to 6. I think it was a
> mistake to expose the accumulator type parameter in other cascading
> collectors
> >> like filtering(), collectingAndThen(), groupingBy(), etc. I'm not
> insisting though, if you feel that conformance to existing collectors is
> >> more important than simplicity.
> >>
> >> With best regards,
> >> Tagir Valeev.
> >>
> >> On Fri, Jun 15, 2018 at 5:05 AM Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >>
> >>> Well, I don't see the need to pack the two results into a Map.Entry
> >>> (or any similar) container as a drawback.
> >>   From an "integrity of the JDK APIs" perspective, it is unquestionably
> a
> >> drawback.  These items are not a Key and an associated Value in a Map;
> >> it's merely pretending that Map.Entry really means "Pair".  There's a
> >> reason we don't have a Pair class in the JDK (and no, let's not reopen
> >> that now); using something else as a Pair proxy that is supposed to have
> >> specific semantics is worse. (It's fine to do this in your own code, but
> >> not in the JDK. Different standards for code that has different
> audiences.)
> >>
> >> Tagir's proposed sidestepping is nice, and it will also play nicely with
> >> records, because then you can say:
> >>
> >>        record NameAndCount(String name, int count);
> >>
> >>        stream.collect(pairing(collectName, collectCount,
> NameAndCount::new));
> >>
> >> and get a more properly abstract result out.  And its more in the spirit
> >> of existing Collectors.  If you want to use Map.Entry as an
> >> _implementation detail_, that's fine.
> >>
> >> I can support this form.
> >>
> >>> I also don't see a larger abstraction like BiStream as a natural fit
> >>> for a similar thing.
> >> I think the BiStream connection is mostly tangential.  We tried hard to
> >> support streams of (K,V) pairs when we did streams, as Paul can attest,
> >> but it was a huge complexity-inflater and dropping this out paid an
> >> enormous simplification payoff.
> >>
> >> With records, having streams of tuples will be simpler to represent, but
> >> no more performant; it will take until we get to value types and
> >> specialized generics to get the performance we want out of this.
> >>
> >>
>
>