On Mon, 21 Mar 2016, David Jenkins wrote:
On 3/21/16 2:55 PM, Michael Van Canneyt wrote:
We can introduce a property which disables the check, if you want.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
However.......... now that I've thought about it some more. That change
would be nice and all for us but doesn't it just muddle the picture even more
for anyone else using the code?
I'm feeling tempted to argue against my side a little. If the change is
correct i.e. makes for better code or behavior then it should stay and we'll
go ahead and take it out in our local files if we don't like it (we'll
grumble at having to maintain a local patch be we already have a few of
those).
My thought is that it doesn't make for better code or behavior while at the
same time breaking Delphi compatibility. Delphi compatibility isn't the
golden standard but it seems any breakage should be for a good reason.
The reason for this behaviour is that find needs to be sure that the list is
sorted.
If it thinks the list is not sorted, the result cannot be guaranteed to be
correct, and this is an error condition.
What I don't understand about these discussions is:
TStringList is just one possible implementation of TStrings.
It is only there for your ease of use.
If you don't like it, you can use another one. You can find several.
There is one in inifiles, the LCL probably also contains a couple.
If all APIs work with TStrings, then they don't care what TStrings
descendent you use. So you are free to use one that does whatever you want.
Anyone declaring an API that explicitly expects TStringList, is simply
doing something wrong, in my view.
This is Object Pascal for a reason, after all.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
