Show quoted text 11 lines
Hi everybody!
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.
The reason for not using the generic based version is that the generics code is slower.
That is what I meant with unnecessary overhead
Show quoted text 10 lines
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.
Variation one:
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.
I don't see the value of this proposal.
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.
Show quoted text 10 lines
Variation two, more flexible:
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).
I can understand an extension where you want to be able to sort on the value
of an associated object. But as you point out, the Find or IndexOf will then
become useless.
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.
So the question then becomes whether you would not be better off with another class altogether if you want such customized behaviour.
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.
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.
Do not forget that TStringlist is just a possible implementation of TStrings. You are free to create your own. For example, the inifiles unit has a
specialized version which is optimized for containing name=value pairs.
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.
Franz
