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 16:12:42 -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.
Why? It's just a warning.
>
Clearly one would want to ensure that one did not call
>
-compare: on NSString with anything but another NSString!
Then, it seems, typecasting both the receiver and the argument would solve
your problem.
NSComparisonResult result = [(NSString *)object1 compare:(NSString
*)object2];
Have you tried that?
>
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.
No, I don't' think so. The compiler is saying you might (but won't
necessarily) raise exceptions, depending on what you pass to the comparison
method. If, on the other hand, you carefully pass only strings, you're
fine. You're program will work.
If you have the compiler set to treat warnings as errors, that implies that
you can't tolerate this degree of slop, so you need to typecast or write a
more generalized version of compare: that deals with the possibility that
the comparands (is that a word?) are not comparable.
>
>
>
> 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.
It will if the signature takes a generic object, such as:
-(NSComparisonResult) compareToObject:(id)anotherObject
Then you would have to check to make sure the objects were comparable, then
compare them.
>
This will, in fact,
>
add one more to the list of multiple definitions.
Not if you name it something else. See above.
Jonathan
_______________________________________________
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.