Le 07/11/2012 22:40, Jonathan M Davis a écrit :
On Wednesday, November 07, 2012 21:31:13 deadalnix wrote:
OK, overall, .peekFront seems like a good idea. Something I'm afraid
with .peekFront is code duplication.
Let's take the joiner example. Joiner's transientness depend on its
source transientness. This seems to me like a very common case for
transformer ranges. If we choose the .peekFront, the naive thing to do
is to implement the same algorithm twice, using front and peekFront,
which is code duplication, and usually a bad idea.
Why would you need to duplicate anything?. If you can implement it using
peekFront, then you use peekFront. If you can't, you use front. And anything
which uses front when you could have used peekFront will still work. Also, if
a free function peekFront which forwards to front is defined, then all range-
based functions can use peekFront if they need it regardless of whether a
range defines it (it's just that it would do the same as front in the case
where the range didn't define it).
- Jonathan M Davis
OK, seeing your answer and H. S Teoh, I think I badly expressed myself,
because none of you understood. Let's try to explain it better.
So back on our joiner range. This range have a source, and will be given
to a consumer as follow :
source -> joiner -> consumer .
Now let's consider that source provide its own, transient peekFront. Now
joiner can provide both peekFront (based on source.peekFront), which is
transcient and front (based on source.front) which is not transcient.
The fact is that both front and peekFront in joiner will have the same
implementation, because the transience of joiner depends of the
transience of its source (like most tranformer ranges).
Or, with sample code :
struct Joiner {
R source;
// Fields and range stuffs.
@property front() {
// Some computation using source.front
}
@property peekFront() {
// Exact same computation using source.peekFront
}
}
I hope this make the code duplication more apparent.
It is impossible for joiner to provide only a version with peekFront,
because joiner.front will be transient, and if it doesn't provide the
version with .peekFront, it can't take advantage of the improvement that
transience can provide.
So my question is, how this duplication can be avoided ? If it can,
.peekFront is definitively the way to go. But if it can't, this seems
like a really problematic point.
