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
