Re: multiple definitions of compare: -- design flaw?
Re: multiple definitions of compare: -- design flaw?
- Subject: Re: multiple definitions of compare: -- design flaw?
- From: Dave Camp <email@hidden>
- Date: Thu, 10 Jul 2003 12:54:07 -0700
On Thursday, July 10, 2003, at 10:21 AM, Brent Gulanowski wrote:
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.
Yes, I've run into this exact same problem. Judging by the responses
here, you have to experience the warning in your own code to fully
appreciate the problem...
On Thursday, July 10, 2003, at 12:13 PM, James Quick wrote:
The warning is useful alerting you to a possible runtime mismatch. It
is quite easy to quiet the warning.
Let's say your front end takes arguments as type id.
Your class determines the comparison argument arg1 must be sent to an
NSString comparison
method. When you pass arg1 to a method expecting a string you will
simply use a typecast
operation to declare the type. This would look like [aString compare:
(NSString *) arg1].
That's not the problem. In the cases where I've seen the warning,
_everything_ was properly statically typed. Yet the compiler continues
to warn about a possible mismatch. The object the compare message was
going to was typed, as all the parameters were typed properly for the
message.
Guess I should submit a bug and some sample code...
Dave
---
The path of least resistance, it's not just for electricity any more.
_______________________________________________
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.