← Back to team overview

ooc-dev team mailing list archive

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



1. Single pass iterators (forward for ordered collections)
2. Bidirectional iterators (only on ordered collectons)

So then the dicussion moves to other operations on iterators.

Should it allow removal/insertion/replacing/use as an lvalue reference.

On Thu, Jun 3, 2010 at 2:59 PM, Noel Cower <ncower@xxxxxxxxx> wrote:

> Responding to what Iván said, so apologies for having Amos's response in
> there too.
> We already have three kinds of iterators: Iterators (simple forward moving
> iterators, probably what your AdvanceIterator is in the example),
> BackIterators (bidirectional), and ReverseIterators (bidirectional iterators
> that wrap other bidirectional iterators and transpose their prev/next
> calls).  I don't think you'll ever see anyone extend the ReverseIterator, so
> that ought to leave two base iterator types.  There are also the two base
> iterable types: Iterable (forward only) and BackIterable (bidirectional).
> As far as I'm concerned, the two base iterator types cover the entirety of
> possible iterators you could need, unless for some reason you want up/down
> and such as well.  The prospect of that scares me.  Same probably goes for
> Iterable/BackIterable as well, although you could probably conceive of more
> abstract classes on top of those (like List).
> That said, the generic function really seems like overkill to me, and I'd
> prefer not to ever have to type so much just for an iterator.  If I can
> leave it at this:
> iter := list iterator()
> ... then my world will be a better place, because that means no code has to
> be changed anywhere and nobody has to do a thing to work with a new kind of
> collection that may or may not support some specific kind of iterator or
> what have you.
> Anyhow, in short, I think we've got enough base iterator types to last us,
> don't think anymore are needed right now, and really don't want to use
> generics for the sake of using generics (or templates, in this case).  I'd
> use C++ if I wanted that.  Hopefully that makes sense, since I started
> writing this a while ago and I'm not sure about the coherency of my e-mails
> after I've tweaked them for so long.
> -noel (nilium)
> 2010/6/3 Amos Wenger <amoswenger@xxxxxxxxx>
>> 2010/6/2 Iván Hernández <ivanhv77@xxxxxxxxxxx>
>>> I think it should not be a front() back() pair methods, as it doesn't
>>> have sense for certain collections, let's say sets.
>>> As direction of traversal is a property of the iterator (not the
>>> collection type), why not have different types for iterator? In a set,
>>> you'll have one possible iterator. In a double linked list you could
>>> have two (from head to back and back to front). You could be using more
>>> than two in other structures (trees can be traversed in preorder,
>>> inorder or postorder).
>>> I belive best solution is to have a generic function for obtaining the
>>> iterator, parameterized with the concrete type of it (representing the
>>> method of traversal).
>>> In exemple, in a list from front to back:
>>>   list iterator<AdvanceIterator>()
>>> or back to front:
>>>   list iterator<ReverseIterator>()
>>> In a tree in preorder:
>>>   tree iterator<PreOrderIterator>()
>>> Problem with that solution is that for keyword looks complex:
>>>   for (item in list iterator<ReverseIterator>())
>>> But if you take into consideration most of the time you're using the
>>> same iterators in a collection, it would be easy to have a
>>> defaultIterator property in a collection that returns the iterator for
>>> the typical traversal in that collection, so
>>>    for (item in list)
>>> could be transformed by the compiler into this:
>>>    for (item in list defaultIterator)
>>> where defaultIterator would be a call to iterator<AdvanceIterator> in
>>> list collection types.
>>> Maybe I'm talking nonsense and I did not catch the point of discussion.
>>> Hope I'm not.
>> I don't see the advantage of having a 'parameterized' method iterator
>> (also considering it's not possible to do something like that in ooc. That's
>> a C++-ism you're writing there, for a language with templates. ooc has
>> generics, which are different). I think in that case, using templates is
>> far-fetched and useless. Having two abstract classes like we discussed above
>> solves neatly the problem, imho.
>> Amos
>> _______________________________________________
>> 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
> _______________________________________________
> 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