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

Reply via email to