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

Zheka Kozlov orionllmain at gmail.com
Tue Sep 11 01:42:09 UTC 2018


public static <T, A, R, RR> Collector<T, A, RR> collectingAndThen(
                                 Collector<T, A, R> downstream,
                                 Function<R, RR> finisher);

public static <T, R1, R2, R> Collector<T, ?, R> collectingAndThen(
                                 Collector<? super T, ?, R1> downstream1,
                                 Collector<? super T, ?, R2> downstream2,
                                 BiFunction<? super R1, ? super R2, ?
extends R> finisher);


сб, 8 сент. 2018 г. в 20:00, Tomasz Linkowski <t.linkowski at gmail.com>:

> Hello,
>
> I'm responding to the thread at [1] (I'm not sure whether my message will
> get appended to it) and the CSR at [2].
>
> I stumbled here from StackOverflow where - indepedently of all the others -
> I also came up with this type of "dual" *Collector* [3]. I named it
> "collectingBoth" there but I'd like to suggest a slightly different name
> here.
>
> I believe that Zheka Kozlov made a great observation about similiarity to
> "collectingAndThen" [4]. And it seems Brian Goetz favors the "AndThen"
> suffix [5]. On the other hand, this new Collector differs from
> "collectingAndThen" in that:
> 1) it hides the accumulation type parameters (A1, A2), and
> 2) it needs a few lower bounds on some of its type parameters.
>
> All in all, I'd like to propose to name the method "collectingBothAndThen"
> (or alternatively: "biCollectingAndThen".
>
> As an aside, I'd like to suggest changing the name of the parameter from
> "merger" to "biFinisher":
> 1) Peter Levart pointed out in [6] that "finisher" is already taken by the
> Collector API (and it's true), but it didn't prevent "collectingAndThen"
> from taking a "finisher" and then
> calling: downstream.finisher().andThen(finisher)
> 2) note that in all other contexts "merger" represents a BinaryOperator
> because it merges two values of the *same* type, and here the types of
> merged values are different.
>
> Complete signatures for comparison below:
>
> *<T,A,R,RR> Collector<T,A,RR> collectingAndThen(*
> *    Collector<T, A, R> downstream,*
> *    Function<R, RR> finisher)*
>
> *<T,R1,R2,R> Collector<T,?,R> collectingBothAndThen(*
> *    Collector<? super T, ?, R1> downstream1,*
> *    Collector<? super T, ?, R2> downstream2,*
> *    BiFunction<? super R1, ? super R2, R> biFinisher)*
>
>
> As to the other potential names, I must say:
> - I'm not in favor of "teeingAndThen" nor all the duplex-related names (I
> find them unintuitive, especially the "teeing" one),
> - I really like "composite" and "compound" proposed by Stuart Marks [7]; it
> seems that "compouding" could be both intuitive and adhering to the -ing
> suffix convention
>
> [1]
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054718.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8209685
> [3] https://stackoverflow.com/a/52211175/2032415
> [4]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053922.html
> [5]
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054736.html
> [6]
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054724.html
> [7]
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054949.html
>
> --
> Regards,
> Tomasz Linkowski
>


More information about the core-libs-dev mailing list