[Lazarus] Easiest way to "case" strings

[Graeme Geldenhuys]

On Fri, Mar 27, 2009 at 3:22 AM, Hans-Peter Diettrich
<DrDiettrich1 at aol.com> 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/