Reputation: 873
I've had reports, confirmed by me, that one of the features in one of my apps breaks under 10.7.3. Upon investigation, it seems that 10.7.3 introduced a private -stringForKey:
method on NSDictionary
.
[NSDictionary respondsToSelector:@selector(stringForKey:)]
returns NO, as one would expect.
But I have a category method on NSDictionary
to implement a -stringForKey:
method, as follows (so it can be used for NSNumber
and NSDate
values too). Under 10.7.2 and earlier, it works fine; under 10.7.3, it returns nil. Getting the object and description directly works fine. So it must be a category conflict.
- (NSString *)stringForKey:(id)key;
{
return [[self objectForKey:key] description];
}
I guess this is another argument in favor of prefixing category methods, despite advice I got from an Apple Application Frameworks Evangelist.
Can others confirm this? I don't think it's a third-party app conflicting; I think it's a change in 10.7.3.
Upvotes: 0
Views: 306
Reputation: 185671
You should always prefix category methods you create on framework classes. No question about it. It doesn't matter whether or not 10.7.3 introduced this method, the fact that you're declaring it without a prefix is wrong.
Incidentally, testing [NSDictionary respondsToSelector:@selector(stringForKey:)]
isn't necessarily going to work. NSDictionary
is a class cluster, so you're just asking the abstract superclass, whereas private methods may only exist on concrete subclasses.
Upvotes: 2