[Lazarus] A bit off topic: iPhone developers

[ik]

On Fri, Mar 27, 2009 at 02:22:17AM +0100, Hans-Peter Diettrich wrote:
> Graeme Geldenhuys schrieb:
> 
> > HasNext()         Returns true if the collection has more items
> >                   when traversing the collection in the forward
> >                   direction.
> 
> This (and the Peek methods) require that the collection is organized 
> strictly sequential, for Previous in both directions.

Not really. It only says that you need either a way to determine if there
are more elements or one element lookahead.

 I have my doubts about previous being part of the base iterator though.
That is as limiting as a "everything is a vector" approach to iterators.

Just "eof" and "next" should be it. If you want to go backwards, see if the
collection provides a separate iterator for the backwards motion. But having
it in the base spec means that it is defunct half of the time, and, like
vector is a too complicated abstraciton for an iteration.

> The implementation for an DataSet can consume an considerable amount of
> time for such operations. It looks to me as if such an iterator interface
> has very limited practical use.

Why is would this slower than a vector <count/items> type of iterator?
Because one can implement a real iterator on top of a vector
(hasnext:=(currentrec<count))

> > Remove()          Removes from the collection the last item that
> >                   was returned by the Next() or Previous() calls.
> >                   (optional modifier operation)
> > SetItem(item)     Replaces the last item returned by the Next()
> >                   or Previous() calls with the specified item.
> >                   (optional modifier operation)
> 
> Which element will the iterator represent, after such an operation? 

The first not seen element or end-of-iteration.

> After Remove it has to represent the next or previous item, depending on 
> the direction of traversion.

> > A *huge* benefit of using iterators, is that the developers doesn't
> > need to worry about if the list/container is 0-based or 1-based, how
> > to get the next or previous item etc... It now gives the developer a
> > consistent interface API to work with, no matter what is being
> > iterated.
> 
> Nice try, but I prefer the slimmer Count and Item[] interface,

Problem is that that requires to know the count up front, AND you can't nest
it in the way you can streams.

(have an iterator B that iterates with iterator A over a collection, but skip some)