[fpc-devel] Questions on TStringList.Find change (Mantis 28744)

[David Jenkins]

On 3/22/16 9:43 AM, Michael Van Canneyt wrote:
>
>
>
> Here we disagree.
> It IS buggy behavior. Delphi is not sacrosanct, it does contain bugs like
> any software. This is one of them.
>
>

No one here holds Delphi up on a pedestal - least of all me.  My 
viewpoint is completely practical/funcitonal - I have to make our code 
base work with FPC/LCL and VCL.  Given the way we use find functionality 
(with a mixture of naturally sorted and automatically sorted lists) it 
has ceased to work with both (it did previously). I want to fix that as 
elegantly and as effectively as possible. Making suggestions for FPC 
improvement is a side effect - and as we both agree TStringList.Find can 
use some improvement.

And I am fine disagreeing.  My definition of 'bug' is again completely 
functional.  If I knowingly stick in a naturally sorted list into 
Find(), the code operates as expected without error, and I get the 
desired result.  Both user and producer operated as expected - by 
intention not by accident.  I do not see a bug there.

If I stick in a non-sorted list (knowingly or unknowingly) then results 
are undefined.  Is that user error or buggy code?  It certainly isn't 
robust code and can be improved.  Label it as you like I am only 
interested it seeing it improved.

As we have all pointed out there is some inherent issues with a function 
traditionally named 'find' that essentially hides input requirements 
(again label that as you like).  Michalis has pointed out that 
TFSMap.Find has a similar issue.

The other weakness I see in the current traditional implementation 
(Delphi and FPC) is that the 'Sorted' flag is somewhat loosely coupled 
to the actual state of the list i.e. it can be in a sorted state and the 
flag does not reflect that at all.  To me it seems that the flag really 
means 'auto sort this please'.  Once it is enabled the code will sort 
and maintain sort.   But the code is also intended to support naturally 
sorted lists and not induce the overhead of auto sort.  In that 
situation the sorted property has nothing to do with the actual state of 
the list.  IMO better designed code would account for this.

Perhaps it should have been called TStringSortedList and enforced auto 
sort all the way through instead of purposely handling both sorted and 
unsorted lists.

As to our decision to use TStringList directly.  Whether we use it 
directly or create our own doesn't fix the code that we all agree is 
insufficiently robust, 'buggy', 'prone to allow bad use', or whatever 
label you want to use.  So I find your concern touching but not 
applicable to the point at hand.

Furthermore TStringList has provided exactly what we needed (and we have 
been careful to only pass sorted - natural or automatic - to it).  Why 
would we purposely rebuild the wheel.  Libraries exist for just this.

And that's all I have to say about that (as Forrest Gump said). Thanks 
for the discussion.

David