Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
- Subject: Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
- From: Martin Wierschin <email@hidden>
- Date: Mon, 07 May 2012 16:07:08 -0700
>> As Jens mentioned, that doesn't make any sense. What good is a localized comparison method if not for sorting a list for display? I suppose you could be implying that Cocoa's sorting methods aren't optimized to assume comparisons are transitive (or special cases problematic strings/comparisons), but that seems quite unlikely.
>
> You're both sliding right over the specifics of what I said:
>
> 1. You cannot reasonably use 'localizedCaseInsensitiveCompare:' *alone* to sort and later insert strings into a list of strings that is "case insensitive" in the sense you originally seemed to mean.
I'm sliding over the details of what you said because they're irrelevant for my purposes. All I need is a consistent/transitive comparison, which I think is a reasonable expectation. Again, jumping straight to the point:
> The best you can do with NSString *only* is to assume that words like "laßt" are just mis-spelled English words (if your locale is us_EN). You can't then expect them to sort like they would in their actual language, though of course you can expect transitivity in the comparison methods.
That's all I expect. I don't care where "laßt" is placed in the sort order for "en_US" (or any other locale), just that it has a single consistent location (so long as the same locale is always used for all comparisons).
> 3. You *did* demonstrate (and 2 other people confirmed) a case-insensitive transitivity failure for us_EN in 10.6.8. Markus found no transitivity failure for de_AT; I found no transitivity failure for us_EN in 10.7.3, though you reported you did;
That's correct- I reproduced that the comparison is not transitive for some strings with an eszett character on 10.6.8 and 10.7.3 with the "en_US" locale. I have since noticed that the project's base and deployment SDK are set to 10.6, so perhaps the bug only manifests because the frameworks are providing compatibility.
> Maybe give 'localizedStandardCompare:' a try?
Thank you for the idea, but that won't be suitable for me because I need to be able to specify the locale.
Well, I'll try bumping the base SDK to 10.7. If I can still reproduce the issue after that, I'll file a radar.
~Martin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden