multiple definitions of compare: -- design flaw?
multiple definitions of compare: -- design flaw?
- Subject: multiple definitions of compare: -- design flaw?
- From: Brent Gulanowski <email@hidden>
- Date: Thu, 10 Jul 2003 11:34:30 -0400
-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.