RFR: JDK-8205461 Create Collector which merges results of two other collectors

[Tagir Valeev]

Hello, Brian!

Regarding more than two collectors. Some libraries definitely have
analogs (e.g. [1]) which combine more than two collectors. To my
opinion combining two collectors this way is an upper limit for
readable code. Especially if you are going to collect to the list, you
will have a list of untyped and unnamed results which positionally
correspond to the collectors. If you have more than two collectors to
combine, writing a separate accumulator class with accept/combine
methods and creating a collector from the scratch would be much easier
to read and support. A good example is IntSummaryStatistics and the
corresponding summarizingInt collector. It could be emulated combining
four collectors (maxBy, minBy, summingInt, counting), but having a
dedicated class IntSummaryStatistics which does all four things
explicitly is much better. It could be easily reused outside of Stream
API context, it has well-named and well-typed accessor methods and it
may contain other domain-specific methods like average(). Imagine if
it were a List of four elements and you had to call summary.get(1) to
get a maximum. So I think that supporting more than two collectors
would encourage obscure programming.

With best regards,
Tagir Valeev

[1] https://github.com/jOOQ/jOOL/blob/889d87c85ca57bafd4eddd78e0f7ae2804d2ee86/jOOL/src/main/java/org/jooq/lambda/tuple/Tuple.java#L1282
(don't ask me why!)

On Sat, Sep 15, 2018 at 10:36 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> tl;dr: "Duplexing" is an OK name, though I think `teeing` is less likely
> to be a name we regret, for reasons outlined below.
>
>
> The behavior of this Collector is:
>   - duplicate the stream into two identical streams
>   - collect the two streams with two collectors, yielding two results
>   - merge the two results into a single result
>
> Obviously, a name like `duplexingAndCollectingAndThenMerging`, which,
> entirely accurate and explanatory, is "a bit" unwieldy.  So the
> questions are:
>   - how much can we drop and still be accurate
>   - which parts are best to drop.
>
> When we pick names, we are not just trying to pick the best name for
> now, but we should imagine all the possible operations one might ever
> want to do in the future (names in the JDK are forever) and make a
> reasonable attempt to imagine whether this could cause confusion or
> regret in the future.
>
> To evaluate "duplexing" here (which seems the most important thing to
> keep), I'd ask: is there any other reasonable way to imagine a
> `duplexing` collect operation, now or in the future?
>
> One could imagine wanting an operation that takes a stream and produces
> two streams whose contents are that of the original stream.  And
> "duplex" is a good name for that.  But, it is not a Collector; it would
> be a stream transform, like concat.  So that doesn't seem a conflict; a
> duplexing collector and a duplexing stream transform are sort of from
> "different namespaces."
>
> Can one imagine a "duplexing" Collector that doesn't do any collection?
> I cannot.  Something that returns a pair of streams would not be a
> Collector, but something else. So dropping AndCollecting seems justified.
>
> What about "AndThenMerging"?  The purpose of collect is to reduce the
> stream into a summary description.  Can we imagine a duplexing operation
> that doesn't merge the two results, but instead just returns a tuple of
> the results?  Yes, I can totally imagine this, especially once we have
> value types and records, which makes returning ad-hoc tuples cheaper
> (syntactically, heap-wise, CPU-wise.)  So I think this is quite a
> reasonable possibility. But, I would have no problem with an overload
> that didn't take a merger and returned a tuple of the result, and was
> still called `duplexing`.
>
> So I'm fine with dropping all the extra AndThisAndThat.
>
> Finally, there's one other obvious direction we might extend this --
> more than two collectors.  There's no reason why we can only do two; we
> could take a (likely homogeneous) varargs of Collectors, and return a
> List of results -- which itself could then be streamed into another
> collector.  This actually sounds pretty useful (though I'm not
> suggesting doing this right now.) And, I think it would be silly if this
> were not called the same thing as the two-collector version (just as it
> would be silly to have separate names for "concat two" and "concat n".)
>
> And, this is where I think "duplexing" runs out of gas -- duplex implies
> "two".  Pedantic argue-for-the-sake-of-argument folks might observe that
> "tee" also has bilateral symmetry, but I don't think you could
> reasonably argue that a four-way "tee" is not less of an arity abuse
> than a four-way "duplex", and the plumbing industry would agree:
>
> https://www.amazon.com/Way-Tee-PVC-Fitting-Furniture/dp/B017AO2WCM
>
> So, for these reasons, I still think "teeing" has a better balance of
> being both evocative what it does and likely to stand the test of time.
>
>
>
>
> On 9/14/2018 1:09 PM, Stuart Marks wrote:
> >
> > First, naming. I think "duplex" as the root word wins! Using
> > "duplexing" to conform to many of other collectors is fine; so,
> > "duplexing" is good.
>