"Dan Sugalski" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >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... :) Next and previous are > actions on the container.
Whatever you name the next/previous operations, you need a way to distinguish operations on the container from operations on the containee -- i.e. the C<deref> operator. Otherwise how would you iterate over a list of iterators? And if you're going to have a deref operator, how much benefit do you actually derive from having ops like C<inc> and C<dec> do an auto-deref. Personally, I like the flexibility of the C++ approach (though some of its limitations will hopefully be fixed in a future iteration of the standard). Being able to add/subtract values other than 'one' to/from an iterator can be useful, especially when iterating over an array. Then C<reset> can be implemented by subtracting the current C<pos>; and C<last> is implemented by adding "size-pos" (modulo an out-by-one error). Incidentally, the ability to implement C<reset> implies that an iterator has some way of finding its parent container. This adds an overhead, which is probably why C++ doesn't do this. A lightweight implementation requires the client-code to track the container, and then add/subtract methods are more compelling than next/prev, because they enable reset/last to be higher level concepts. Does/will parrot do run-time bounds checking to ensure you don't run off the end of a container? Dave.
