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 19:37:29 -0400
I am going to try to clarify a little. Although I do like the idea of
putting a category on NSObject, now that I see how it would work.
I don't want to statically type because then I have to write more code.
I don't have to worry about type mismatches because I am comparing
something like this:
-(void)sortForKey:(NSString *)keyName {
[CustomObject setSortKey:keyName];
[myArrayOfCustomObjects sortUsingComparator:@selector(compare:)];
}
in my CustomObject class, I have this:
-(id)objectForKey:(NSString *)key {
return [myDictionary objectForKey:key];
}
-(void)compare:(id)other {
id value = [myDictionary objectForKey:sortKey]; // sortKey is a global
for the class
id otherValue = [other objectForKey:sortKey];
return [value compare:otherValue];
}
It's fairly neat and clean, no switches or if statements or typecasts.
Because the objects are the same class and the dictionary entries for
the same key are the same class, I know it's safe. I guess that it
could be argued that the dictionary entries could be screwed up, but
static typing won't solve that. For now I am just ignoring the warning
that results.
On Thursday, July 10, 2003, at 01:21 PM, Brent Gulanowski wrote:
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.
No one really knows enough to be a pessimist. -- William Blake
_______________________________________________
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.