← Back to team overview

ooc-dev team mailing list archive

Re: Back/front methods for Iterable (and reverse iterators)

 

Hey there.

Your additions make perfect sense, a few comments though:

   - Aren't there any better names for 'front' and 'back' ? while
   'frontIterator' etc. would be a little long, maybe there is a more explicit
   name someone can come up with?
   - If we eventually agree on names for 'front' and 'back' I'd like to
   deprecate 'iterator' - I don't like having aliases
   - Also, maybe it'd be good to document a bit more the data structure
   classes along the way (even if it's only one) - as I mentioned on the chan,
   os/Process is more or less a good example of it. Oocdocs are delimited by
   /** */, Tags are :likethis: (e.g. :author:, :param:, :return:) For more
   info, bug fredreichbier about how oocdocs work together with Sphinx and why
   rock's JSON backend is currently disabled.

Once that is settled I will gladly merge that into master.

Amos Wenger (nddrylliog)

P.S: You got the mailing list's adress right, now all you need is to not
forget to hit 'Reply to all', and not simply 'Reply'

On Wed, May 26, 2010 at 12:57 AM, Noel Cower <ncower@xxxxxxxxx> wrote:

> 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)
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev
> Post to     : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References