ooc-dev team mailing list archive

[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