Please be mindful of the request Viktor made: for feedback on the
approach and the API concepts. It should be pretty clear that low-level
details like "unsupportedCombiner" are many levels down below "approach
and concepts". (And, you know the rule: when you bikeshed on a
low-level detail when asked for high-level comments, you've forfeited
the right to have further opinions about the concepts.)
In any case, I think your high-level comments seem to be: you prefer a
direction where, rather than creating new possibly-stateful,
possibly-not-parallel ops, instead beef up Collector and let people
start a new stream.
On 6/29/2023 8:13 AM, fo...@univ-mlv.fr wrote:
>The idea of unsupportedCombiner() seems out of place, like a
patch to be able to clobble different things together. I'm not
sure to understand why it's needed for a Gatherer, and why it is
not needed for Collectors ?
Nothing prevents us from treating a `null` combiner the same way.
My primary reason for making it a dedicated thing was to be able
to differentiate a possible bug (user passing in a null reference
inadvertently) from explicitly stating that a combiner does not
exist from this operation.
/unsupportedCombiner()/ as an artifact can be completely hidden if
desired, as /Gatherer.of()/ can have permutations without
specifying a combiner, and the /default method/ of
Gatherer.combiner() could return /unsupportedCombiner()/. I opted
not to do this initially, because I felt like being explicit about
not having a combiner means that it is a concious decision by the
implementor of the Gatherer.
My question is more, why do we need this unsupportedCombiner on a
Gatherer and not on a Collector ?
