Take a simple program like this:
/* main.m */ #import <Cocoa/Cocoa.h>
int main () { id a = nil, b = nil; [a compare:b]; return 0; }
It outputs the following warnings:
main.m: In function main':
main.m:7: warning: multiple declarations for method compare:’
/System/Library/Frameworks/Foundation.framework/Headers/NSValue.h:53: warning: using -(NSComparisonResult)compare:(NSNumber *)otherNumber'
/System/Library/Frameworks/Foundation.framework/Headers/NSDate.h:29: warning: also found -(NSComparisonResult)compare:(NSDate *)other’
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:74: warning: also found `-(NSComparisonResult)compare:(NSString *)string’
Is there anyway to suppress this crap, without having to specifically provide a type for id?
The easiest answer is to add a category on NSObject specifying a generic -compare:, i.e.
@interface NSObject (UniversalCompare)
You don’t even need to provide an implementation; just providing the interface is enough to satisfy the compiler. – Bo
That’s a great idea, Bo. Now if only I could reconcile -(void)draw and -(BOOL)draw by that means…
Unfortunately it does not work :( If I let a and b be NSObject*, then the warnings are left out, but for id they remain.
Shucks. I have to admit I hadn’t tried it under quite those circumstances, though it did seem to work in situations where you were taking an object straight out of a collection (e.g. -objectAtIndex:) and calling -compare: on it, and I thought those returned the id type. Anyway, I guess you could cast it, i.e. [(NSObject*)a compare:b] which is pretty ugly but gets the job done. – Bo
I’m pretty sure the only way to fix that is either to make the objects be a definite class (NSObject?), or to cast them for comparison. Why don’t you just make them NSObjects? You know that an NSObject* can in fact be any object that inherits from NSObject, right? –OwenAnderson
Yes, I do know about inheritance ;-)