[fpc-devel] Stringlist customsort

[Franz Müller]

> 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


> 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.

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20181130/764db799/attachment.html>