<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font size="-1"><br>
</font></p>
<blockquote type="cite" style="color: #000000;"><font size="-1">Hi
everybody!
<br>
</font>
<font size="-1"><br>
Currently, the implementation of cutomsorted stringlists ist
very far from satisfactory; you have to call the sort routine
again whenever a string is added to the stringlist or an item is
changed, because the stringlist cannot keep itself automatically
sorted using a custom compare function. There is a better
implemetation using the "experimental" define FPC_TESTGENERICS,
but this code has not become "mainstream" FPC for a long time
now, and I feel that the use of generics for the implementation
of stringlists will also introduce quite some unnecessary
overhead.
<br>
</font></blockquote>
<font size="-1">
<br>
The reason for not using the generic based version is that the
generics code is slower.
<br>
</font>
<p>That is what I meant with unnecessary overhead<br>
</p>
<p><font size="-1"><br>
</font></p>
<blockquote type="cite" style="color: #000000;"><font size="-1">I
would like to propose one of two versions of improvement of the
non-FPC_TESTGENERICS TStringlist, that I would also be willing
to program and to submit a patch for it.
<br>
</font>
<font size="-1"><br>
Variation one:
<br>
</font>
<font size="-1"><br>
Just add a property OnSort of type TListSortCompare and always
sort using the user-provided function if the property is not
nil. Automatic sorting would only occur if sortstyle=sslauto,
while the behaviour for sortstyle=ssluser would remain as before
for backward compatibility.
<br>
</font></blockquote>
<font size="-1">
<br>
I don't see the value of this proposal.
</font><br>
<p>It would allow stringlists with a non standard sort order (for
example numeric sort instead of alphanumeric) to remain
automatically sorted when items are added or changed. But I also
feel the second variation is better.<br>
</p>
<blockquote type="cite" style="color: #000000;"><font size="-1">Variation
two, more flexible:
<br>
<br>
Add a property OnSort of type TStringListSortCompare, which
would allow stringlists to be sorted not only by the value of
the string, but also by the value of the fields of the
associated object. In that case it would be necessary to add a
new sortstyle sslobject, which would have to be used when OnSort
uses fields from the object for comparing, as in this case the
find method cannot use binary search for locating an item, just
like for unsorted stringlists (and the stringlist wouldn't know
otherwise that it can't use binary search).
<br>
</font></blockquote>
<font size="-1">
<br>
I can understand an extension where you want to be able to sort on
the value
<br>
of an associated object. But as you point out, the Find or IndexOf
will then
<br>
become useless.
<br>
</font>
<p>Useless? Why? Slower - yes. Don't matter with stringlists of a
few dozen up to a few hundred items. If you have more data, maybe
you need a specialized class. <br>
</p>
<p><br>
</p>
<p><font size="-1">So the question then becomes whether you would
not be better off with another class altogether if you want such
customized behaviour.</font></p>
<p><font size="-1">From what you describe, I think you should not be
using TStrings (Or TStringList) at all. TStrings is a very
general-purpose class for use in a GUI, which IMHO should not be
burdened with additional highly specialized mechanisms.
</font></p>
<font size="-1">
</font>
<p>Take a simple example: Suppose you have a drop down box and want
to keep the 5 most recently used items in front, and all the other
items sorted alphabetically. With a custom sort which is not
restricted to the string values for sorting, you could do this
easily by placing an additional value for sorting in the object
field. As the drop down box uses TStrings, you are bound to use
something like a stringlist.<br>
</p>
<br>
<font size="-1">Do not forget that TStringlist is just a possible
implementation of
<br>
TStrings. You are free to create your own. For example, the
inifiles unit has a
<br>
specialized version which is optimized for containing name=value
pairs.
<br>
</font>
<p>Of course, everyone can create his own basic classes for
everything, but I think that is not how high level programming is
supposed to work. The improvement that I propose is 100%
compatible with current code, if you don' t need the feature
(which will be the case most of the time), you just don't use it,
but if you need this added flexibility, it is there. The
implementation is very simple and no complexity is added for
programmers who don't need the feature.</p>
<p><br>
</p>
<p>Franz<br>
</p>
</body>
</html>