On Sunday, 16 June 2013 at 17:37:32 UTC, monarch_dodra wrote:
What made you change the parameter of :
* "pipeOnPop = false" (eg call on front by default)
to
* "pipeOnFront = false" (eg call on pop by default)
?
Actually the original version was pipeOnPop = true by default.
So I didn't change the logic, I just renamed the variable to make
the flag more clear that you would pass in pipeOnFront.yes to
opt-in. (Also to coincide with your comment on the pull request).
I think pipe on front makes more sense, since you'll actually
*see* the last value that was passed if the stream is
terminated, eg:
[1, 2, 3, 4].tee!`writeln("processing: ", a).until!"a > 2"();
Which will output:
processing: 1
processing: 2
<end>
what about 3?
. . .
The *advantage* of pipeOnPop is that each element is piped at
least once, and at most once, so that's good.
I think they both have their advantages, which is why it's
probably important to be able to control the behavior regardless
of which one is default. I choose pipeOnPop as the default
because:
1) It more closely tied in to the idea of tapping into the data
as the wrapped range is iterated over (i.e. calling front
multiple times won't call the function multiple times, as you
said).
2) I felt like I would personally use pipeOnPop more often, and
figured the most commonly used case should not require the flag.
But I'm not especially tied to it, and could see making
pipeOnFront default if that is preferred.
And actually, as I think about what I just wrote and also my
previous unittest example, it almost feels like pipeOnPop gives
you insight into the wrapped range itself, and pipeOnFront gives
you more insight into how the range is used. The incoming vs.
the outgoing, as it were. And I imagine I'd like to know more
about what is coming in more of the time, but that's just my
opinion.
irritate
