|Home » Learning Curve » Developers Workshop
isEqualToString Doesn't Compare
Not always at any rate.
There's a new app under development. Today when work resumed a suggestion was made to change its working title - to something that happened to have a diacritical (non-ASCII) character in it. Said and done.
The project directory was renamed and the directory was double clicked to enter.
Wa? Try again. Same thing. Mess around a bit and ascertain there definitely is an issue. Out with the source to Xfile. Start stepping through the code. Nothing wrong. Everything reports correctly - diacritical and all.
Totally by accident - by chance - a 'corroboration' method is found that uses isEqualToString:. Purely shooting in the dark it's changed to compare:. Suddenly everything works again.
As the ACP is built simultaneously for both Tiger and Leopard and as the default development OS is Tiger for a number of reasons the 'NeXT STEP' was to try the new line of code in Leopard as well.
The build on Leopard went without incident. But before testing the new build the same scenario that failed on Tiger with isEqualToString: was set up on for testing on Leopard.
It didn't fail.
Leading one to the inevitable and unavoidable conclusion there's been a bug in Tiger.
isEqualToString: is often used for string comparisons despite the compare: method also being available. isEqualToString: is supposed to be faster than the more generic isEqual: if both the receiver and first argument are known to be instances of NSString.
When you know both objects are strings, this method is a faster way to check equality than isEqual:.
The comparison uses the canonical representation of strings, which for a particular string is the length of the string plus the Unicode characters that make up the string. When this method compares two strings, if the individual Unicodes are the same, then the strings are equal, regardless of the backing store. 'Literal' when applied to string comparison means that various Unicode decomposition rules are not applied and Unicode characters are individually compared. So, for instance, 'Ö' represented as the composed character sequence 'O' and umlaut would not compare equal to 'Ö' represented as one Unicode character.
compare: has no comparable 'discussion'.
And whilst isEqualToString: may perhaps be allowed (in theory) to behave differently from compare: in certain situations it certainly isn't expected to behave differently in different versions of the operating system.