Re: multiple definitions of compare: -- design flaw?
Re: multiple definitions of compare: -- design flaw?
- Subject: Re: multiple definitions of compare: -- design flaw?
- From: Brent Gulanowski <email@hidden>
- Date: Thu, 10 Jul 2003 13:21:25 -0400
On Thursday, July 10, 2003, at 12:45 PM, Jonathan E. Jackel wrote:
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?
This is exactly my point: I AM writing another class that implements
compare -- only it's actually comparing items in a dictionary which
could be strings or numbers. I did not say that I wanted to compare
objects of different classes, only that I wanted to avoid the compiler
warning. Clearly one would want to ensure that one did not call
-compare: on NSString with anything but another NSString! But the same
program might want to compare two strings, two dates, two numbers or
two custom objects, without having an annoying compiler warning about
multiple declarations. Creating a warning when you aren't doing
anything wrong is ... or might be ... a bug.
That said, you could write your own comparison method in a category on
NSObject or (since you are sorting dictionaries) NSDictionary.
This will not help with my problem, that I can see. This will, in fact,
add one more to the list of multiple definitions.
-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.
--
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.