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: Fri, 11 Jul 2003 10:27:34 -0400
On Friday, July 11, 2003, at 06:31 AM, Bill Cheeseman wrote:
on 03-07-10 11:34 AM, Brent Gulanowski at email@hidden wrote:
-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).
This complaint has been in the mailing list archives for more than two
years. Knowledgeable people seem to feel it is an error, but I see no
sign
in the archives that anybody has actually reported it as a bug.
Perhaps it's
too late to fix it and maintain backward compatibility.
I did try a search on mamasam for "compare AND warning AND sort" or
something, and a couple of other variations, but failed to find it
(although I did figure that it was there). Apple's archives are simply
unusable for this kind of thing.
Why would changing the static types to id have any effect on existing
code?
On Friday, July 11, 2003, at 09:15 AM, James Quick wrote:
On Thursday, July 10, 2003, at 07:37 PM, Brent Gulanowski wrote:
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.
First, your compare: method must return a value, and is declared
(void).
Hmmm, do you think that's maybe because I typed it directly into the
e-mail? Note the return statement at the end.
I think you are confusing "neat, and clean" with short. Brevity,
other things being equal,
is a laudable goal. In this case, other things aren't equal, you are
sacrificing correctness
of the implementation and both reusability and brittleness of the
design in exchange for
a few lines of code. I don't consider that a fair trade.
You intend that the objects being compared are of the same class, and
assume they are.
This may currently be the case. But, neither you, nor the compiler,
can be sure that
this is true in some future runtime. For correct operation this
method *must* know for certain
that the objects have compatible behavior for their own compare
methods, but your code
does not check.
You're right, except this is e-mail code. Does everybody take
everything at face value? Do you think my class is called
"CustomObject", too? I was illustrating a concept.
Even if I check that the two objects are the same (if you have two
dictionaries created by the same custom vending object in the same
application, and you retrieve an object with the same key, exactly how
likely is it that the classes are different? I'd blame the maintainers
for abusing the design). Whatever, the compiler will still complain
because of static typing in the framework, giving me a warning that
nothing I can do -- besides changing the framework -- can turn off.
The framework generates a warning. Does that make sense? Objective-C is
a dynamic language. It's my problem if I forget to check class
matching, or in other cases if I neglect to call -respondsToSelector:.
The id type is there for a reason -- to make code simpler and more
adaptable, and to allow selectors to be re-used by different classes in
the same context. Static typing in that case just contradicts the
spirit of the enterprise.
I'd argue that every selector that doesn't specify a class explicitly
or implicitly in its name ( -setTitle: implies an NSString ), should
not statically type its arguments.
B
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.