← Back to team overview

ooc-dev team mailing list archive

Back/front methods for Iterable (and reverse iterators)

 

Right now we only have one method for getting an Iterator from an Iterable, presumably at the beginning of the Iterable.  As it stands, that's not really very good if you need to iterate back to front, so I went ahead and added a couple methods to Iterable (and String) called front() and back() that return iterators at the front and back of the Iterable (duh).  While I was at it, I added a ReverseIterator class, this just wraps an existing forward iterator and transposes next/prev calls and such; rewrote most of the LinkedList class since it wasn't very good for iterating backwards in the first place; and added back() methods to the other classes in `structs/' that I felt I could add them to (in other words, I left out MultiMap and its subclasses).  All those changes can be viewed in my fork of rock here:

http://github.com/nilium/rock

Anyhow, since the front() method just returns the result of iterator(), I'm wondering if perhaps iterator() should be removed.  Maybe some other change should be made, like moving back/front out of Iterable and just make them methods of each subclass.

Either way, I think this is going to be needed (or at least save a lot of time) for working on things like GUIs (since I'm porting mine over to ooc now-ish), where you'll want to go back to front when rendering views/windows and front to back to propagate events from the tips of the view hierarchy inward. Also has use in games where you may want to iterate in reverse when handling different nodes in the scene graph (I'm not sure about that, but I don't think the way it is right now is sufficient, obviously).

As for reverse iterators, I think what I have is sufficient for most purposes, since if you're going in reverse, it seems obvious (to me, at least) that you'd just want to have prev() called instead of next(), and if you want to pass the iterator off to something else that uses only hasNext/next, then you should be able to transpose those methods easily.

If anyone has any suggestions as to how they think this could be better handled, that'd be appreciated.  At any rate, I hope I just sent this to the right address, since mailing lists confuse the heck out of me…

-noel (nilium)




Follow ups