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

Reply via email to