Replicator (as in DNA) Sent from my iPhone
> On Jun 18, 2018, at 6:49 PM, James Laskey <james.las...@oracle.com> wrote: > > Bifurcate > > Sent from my iPhone > >> On Jun 18, 2018, at 6:29 PM, Brian Goetz <brian.go...@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 <amae...@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.go...@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. >>>> >>>> >> >
