Re[2]: gnustep/2146: call isEqual: to find if a NSString and a NSNumber are equal don't work

[Manuel Guesdon]

On Wed, 14 Mar 2001 22:02:41 +0000 Richard Frith-Macdonald <Richard 
Frith-Macdonald <richard@brainstorm.co.uk>> wrote:
 >| On Wednesday, March 14, 2001, at 09:30 PM, mguesdon@orange-concept.com 
 >wrote:
 >| 
 >| > isEqual: doesn't work to compare a NSString and a NSNumber. 
 >| > NSString* a=[NSString stringWithString:@"1"]; 
 >| > NSNumber* b=[NSNumber numberWIthInti:1]; 
 >| > [a isEqual:b]] or  [b isEqual:a] always return NO 
 >| > It's hard to diagnostic until you print the class of the compared 
 >objectss 
 >| > How does this is handled on NeXT/MacOSX ? 
 >| 
 >| Not a bug ...
 >| 
 >| This is correct behavior as a string is not a number so isEqual: should 
 >always
 >| return NO for a comparison of the two.
 >| 
 >| In general, objects of different classes are not equal ... unless both are 
 >instances
 >| of private subclasses in a class cluster.
 >| 
 >| OPENSTEP and MacOS-X behave the same way.

OK. 
I've came to this problem whith a dictionary in a .plist file indexed by 
"number". I've lost a lot of time to find
why a -objectForKey:[NSNumber numberWithInt:1] didn't work :-( 
When I printed the dictionary and the search key, both appeared (correctly) 
with "1".

Anyway, I see it's not easy to design a isEqual: method to handle all kind of 
situation.

Manuel
--
______________________________________________________________________
Manuel Guesdon - Software Builders <mguesdon@sbuilders.com>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0999  -  Fax: +33 1 4940 0998