java.util.stream.Stream: API for user-extensible intermediate operations
Brian Goetz
brian.goetz at oracle.com
Thu Jun 29 13:11:51 UTC 2023
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, forax at 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 ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230629/0b4fa00f/attachment.htm>
More information about the core-libs-dev
mailing list