ooc-dev team mailing list archive

[Bart van der Werf <bluelive@xxxxxxxxx>]

So:

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
>
>