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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
