Dan Sugalski writes:
> At 1:08 PM -0600 6/14/04, Luke Palmer wrote:
> >Dan Sugalski writes:
> >> Once we decide how to *get* these things (see the previous e-mail) we
> >> need to decide how they should work. We can fiddle around, but
> >> honestly the scheme:
> >>
> >> 1) They act as arrays--if you want the 18th element in the iterator,
> >> access it directly
> >> 2) They have 'next', 'previous', 'first', 'last', and 'reset' methods
> >> to get the next, previous, first, or last element in the iterator, or
> >> to reset the iterator to the beginning. Next, last, and reset change
> >> the internal current element pointer, first and last don't.
> >
> >Why not take a page from C++ and call "previous" and "next" C<inc> and
> >C<dec>, and then C<deref> to get what it points to.
>
> Because ++ and -- affect the value not the container. (There are days
> when I think "C++ does it like..." is the near-perfect argument
> against doing it one particular way... :)
Heh, yeah.
> Next and previous are actions on the container.
Then how, if we have an array of iterators, do we increment an internal
iterator from an external one. That is:
@foo = (1..5);
@bar = map { @foo.iter($_) } reverse 0..4; # make an array of iterators
for @bar  0... -> $x, $c {
if something($x) {
@bar[$c].next;
}
}
Without that awful reference of $c (awful not in a stylistic way, but in
a I-have-to-keep-the-index-around-too-wtf kind of way).
I'm arguing for an iterator to be an I<explicit> pointer, one that you
have to dereference, for this reason.
Luke
