On May 7, 2012, at 13:35 , Martin Wierschin wrote: > 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. Specifically, you cannot determine an order for *different* strings that compare *equal* using this method alone (e.g. "a" and "A"). I never said nor intended to say that localized comparison methods *generally* are useless. Just this one, for this particular purpose. The correct method for this particular purpose seems to be 'compare: … options: NSCaseInsensitiveSearch | NSForcedOrderingSearch locale: nil'. Note that this is *not* a case-insensitive comparison -- "a" and "A" are *unequal* in this case. Another possible alternative is 'localizedStandardCompare:', although there's no API contract here about what strings are equal. This point has nothing to do with the language or character set used by the strings. 2. Case is a *language-dependent* concept. There's *no* answer to the question "Are these two strings equal ignoring case?" unless you know the language of *each* of the strings. NSString has no comparison function that lets you specify the locale -- and hence language -- of each string separately. At best, the localized comparison methods let you specify the locale assumed for *both* strings. This doesn't necessarily mean you can't case-insensitively sort a list of mixed-language strings. It does necessarily mean you can't case-insensitively sort a list of mixed-language strings *using NSString comparison methods only*. 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. 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; no one has reported a transitivity failure other than a case-insensitive comparison involving "ß". There does seem to be a bug here, but the exact set of conditions isn't clear. Maybe give 'localizedStandardCompare:' a try? _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com