Hej Richard,
I have to admit that I needed to read this a number of times before I believe I
understood this. I think the semantics can be hard to understand in any of
these edge cases, but I’ll try to explain how my intuition sees it.
> So I am thinking now that it might make more sense to simply internally set
> the shift from the negative number to 0 when used
> in such a situation:
>
> ----
> select().shifted(-1).following(t3) => {t4, t5} // internally shifted is
> capped to 0
> select().following(t3) => {t4, t5}
> ——
Makes sense if we use a list model with a final begin and end, and I would with
this choice prefer to think of shift as an operation that is limited to the
bounds of the list, meaning it stops once these have been reached, which
effectively means it is capped to 0 in the above example. The alternative is to
take the view of the list as a circular entity with respect to operations like
shift, which is similar to negative list indexes in Python. However, applying
the “following”-operation makes the shift redundant in the above example. Both
operations just move the iterator, so to me it seems irrelevant what shift does
before, since “following” should move the iterator to the specified location
independently of where it was placed by shift.
>
> However, that would/should then introduce interaction with the `limit()`
> operator, e.g.
>
> ----
> select().shifted(-1).following(t3) => {t4, t5} // internally shifted
> is capped to 0
> select().shifted(-1).following(t3).limit(2) => {t5}
> ——
>
> We shift by -1, do not return the result because it is outside the bounds,
> but still limit the
> forward move operations. So effectively, the negative shift would need to be
> subtracted from
> the limit in this case.
>
> Any thoughts?
>
This is not obvious to me. Given my argumentation above, it doesn’t matter what
shift does, since “following” is the last operation that determines the
iterator position, and limit should apply to the iteration from that position.
I would expect it to be independent from shift, except that shift, like
following, changes the iterator position, but limit applies to the iteration
from that point on whatever that is, so I would still expect {t4, t5}. I don’t
see why there should be any direct interaction between shift and limit. I would
think of this like stream operations, except that shift and following don’t
make much sense in the middle of a stream chain, i.e. they can only be applied
during initialisation of the stream source.
Cheers
Mario
________________________________
Disclaimer:
This email and any files transmitted with it are confidential and directed
solely for the use of the intended addressee or addressees and may contain
information that is legally privileged, confidential, and exempt from
disclosure. If you have received this email in error, please notify the sender
by telephone, fax, or return email and immediately delete this email and any
files transmitted along with it. Unintended recipients are not authorized to
disclose, disseminate, distribute, copy or take any action in reliance on
information contained in this email and/or any files attached thereto, in any
manner other than to notify the sender; any unauthorized use is subject to
legal prosecution.
