RE: multiple definitions of compare: -- design flaw?
RE: multiple definitions of compare: -- design flaw?
- Subject: RE: multiple definitions of compare: -- design flaw?
- From: "Jonathan E. Jackel" <email@hidden>
- Date: Thu, 10 Jul 2003 12:45:42 -0400
The problem with comparing, say, a date with a string is that there is no
obviously correct order. Some programs might always put the date first,
some might always put the string first, and some might convert the date to a
string representation to compare it with the other string. Plus, what about
all the other classes in Foundation? What about classes that aren't in
Foundation, like the ones you might right?
That said, you could write your own comparison method in a category on
NSObject or (since you are sorting dictionaries) NSDictionary.
Jonathan
>
-----Original Message-----
>
From: email@hidden
>
[mailto:email@hidden]On Behalf Of Brent Gulanowski
>
Sent: Thursday, July 10, 2003 11:35 AM
>
To: email@hidden
>
Subject: multiple definitions of compare: -- design flaw?
>
>
>
-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).
[snip]
>
>
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
_______________________________________________
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.