Question

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.

Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top