ooc-dev team mailing list archive

[Noel Cower <ncower@xxxxxxxxx>]

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