On Fri, Mar 27, 2009 at 3:22 AM, Hans-Peter Diettrich <[email protected]> wrote: >> 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. 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.
I have not used TDataSet or TClientDataset components in years, but from what I remember they retrieve a few records at a time, it the source is huge. As for working with my data via tiOPF, my lists are always fully populated, but with partial objects - the object is in a posPK state and not a posClean (fully populated) state. So I can retrieve a lot more records (objects) with a penalty. Objects are then fully populated as I need them. Also, I don't blindly do a 'select * from', my GUI interface always has some filter before I retrieve any data. As for limited practical use - that is debatable. I find them very useful. Not to mention every java container/list class has built in iterator support. It java everything uses iterators! >> 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? > After Remove it has to represent the next or previous item, depending on > the direction of traversion. Which is handled very easily - my article explains this clearly. Each iterator has a FCursor private field that tracks the cursor position. My iterators are implement as in the Java-style iterators, which means they point between elements and not at elements. Hence the reason I don't have a iterator.Current(..) API call. This makes implementing modifier methods like Remove() much easier as well. If you want, I can send you my article and code which should explain all this and more much clearer. > Nice try, but I prefer the slimmer Count and Item[] interface, with a > chance to remember the index of a found item, and with immediate use of > an item without an type cast. Excuse me, but I don't have a single type cast in my code either. Have you actually tried iterators before? Not having to worry about how to access the list element, if the list is 0 or 1 based, no counter variable etc are all huge bonuses for me. Plus I can switch internal list/container classes in my business objects with minimal code changes to my iterators. I just need to change the iterator type, simply because the iterator interface does not change, no matter what list/container class I am iterating. So the way of accessing the elements in a list never changes. > that's not an argument against using collections and iterators at all, > only my personal preference ;-) That's your choice then, but you don't know what you are missing. ;-) Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
