Re: multiple definitions of compare: -- design flaw?
Re: multiple definitions of compare: -- design flaw?
- Subject: Re: multiple definitions of compare: -- design flaw?
- From: publiclook <email@hidden>
- Date: Thu, 10 Jul 2003 13:29:11 -0400
Just use static typing yourself. The following should work without
warnings although I just wrote them in main and haven't tried to
compile:
NSString *aString = @"baz";
NSNumber *aNumber = [NSNumber numberWithInt:10];
NSNumber *anotherNumber = [NSNumber numberWithFloat:345.0];
[aString compare:@"zap"];
[aNumber compare:anotherNumber];
On Thursday, July 10, 2003, at 11:34 AM, Brent Gulanowski wrote:
-compare: is implemented by NSString, NSNumber, and NSDate. That's
great, except they each define the argument using their own class,
instead of id. So if you call -compare:, you are guaranteed to get
complaints from the compiler (and if you have -Wall set, you can't
compile at all).
I was unable to solve the problem by selecting only necessary headers
to #import (as opposed to Foundation.h), because the combination I
needed led to #importing the contradictory headers anyway. (I did not
have to #import NSNumber.h or NSDate.h, but NSGeometry.h and another I
needed did so anyway.)
Is there a reason that the above classes use static typing in their
implementations of -compare:? (I found it interesting that the
argument names aren't even consistent: "string", "otherNumber", and
"other", respectively, I believe).
I was forced to turn off -Wall. If the classes in question had all
declared
-compare:(id)other
would that have been a problem? Should I report this as a bug?
Is there a better solution to avoid the compiler warning? I am sorting
dictionaries based on NSNumber and/or NSString objects contained
therein.
Thanks,
Brent Gulanowski email@hidden
--
Fusion power is the energy of the future, and always will be!
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.