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

Peter Levart peter.levart at gmail.com
Tue Aug 21 07:37:22 UTC 2018


I just note that sometimes naming is hard. Not because there would be no 
suitable name to choose from but because there are too many. In such 
situations it becomes apparent that every individual's brain works 
slightly differently. That said, I must admit that teeingAndThen is not 
my favorite either. The "tee" UNIX command is not "symmetrical". It 
interposes itself into the pipeline as a pass-through element (stdin -> 
stdout) and has (one ore more) additional outputs in the form of files. 
The name "tee" comes from T-splitter used in plumbing, where the 
pass-through direction is a straight line (the horizontal on letter T), 
while the additional output is the vertical:

https://en.wikipedia.org/wiki/Piping_and_plumbing_fitting#Tee

Out collector is symmetrical though.

On 08/21/2018 07:43 AM, Stuart Marks wrote:
> a few more names that (mostly) don't seem to have been proposed 
> before, and so here they are for your consideration:
>
>  - compound
>  - composite
>  - conjoined
>  - bonded
>  - fused
>  - duplex
>
> Discussion:
>
> A "composite" evokes function composition; this might be good, though 
> it might be odd in that collectors can't be composed in the same way 
> that functions are.
>
> "Compound" might be a useful alternative. In chemistry, two substances 
> are combined (or bonded, or fused) to form a single substance, which 
> is a compound.
>
> "Conjoin" seems to adequately describe the structure of the two 
> collectors, but it lacks somewhat the connotation of unifying them.
>
> In an earlier discussion, Brian had pushed back on names related to 
> split/fork/merge/join since those are currently in use in streams 
> regarding splitting of input elements and merging of results. In 
> describing how the current proposal differs, he said that elements are 
> "multiplexed" to the different collectors. Since we're doing this with 
> two collectors, how about "duplex"? (I note that Jacob Glickman also 
> had suggested "duplex".) 

My brain likes "duplex".

duplex, duplexing or duplexingAndThen ? I think "duplexing". AndThen 
suffix is not needed. Even if there is a standard Pair class to come in 
the future, overloaded "duplexing" method could be added with no 
ambiguity (mental or javac).

Regards, Peter



More information about the core-libs-dev mailing list