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

[Michael Van Canneyt]

On Tue, 22 Mar 2016, David Jenkins wrote:

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

Yes.

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

"by intention not by accident." 
Clearly this is not the case, given the warning in Delphi's help.

And as a component developer I have a different point of view.
A component should enforce correct behaviour and conditions.

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

No argument there.

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

That's not very handy, I switch sort on and off regularly. This approach
would require me to re-create classes and copy data.

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

It is not so much concern, but wonder; see below.

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

Yes and no, they are general purpose classes:
In general, I don't believe in the 'one size fits all' approach, and think
an argument can be made for custom classes in case of specialized needs.
(which is not to say that general purpose classes should not strive for the best
possible implementation)

In each case, there is no argument that the code can be improved.

We'll sort something out in the end.

Is your preference for an extra argument to Find() or an additional property ?

Michael.