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.linkow...@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 >