Is it safe to use isKindOfClass: against an NSString instance to determine type?

Question

From the isKindOfClass: method documentation in NSObject:

Be careful when using this method on objects represented by a class cluster. Because of the nature

Answer 1

You are reading the warning wrong. All it says is that, just because it is internally represented as something that is mutable, does not mean you should try to mutate it, because mutating it could violate the contract between you and whomever you got the array from; it might violate their assumptions that you will not mutate it.

However, the test given by isKindOfClass: is definitely still valid. If [something isKindOfClass:[NSMutableArray class]], then it is an instance of NSMutableArray or subclass thereof, which pretty much means it's mutable.

Answer 2

Lets consider the following code:

if ([dict isKindOfClass:[NSMutableDictionary class]])
{
    [(NSMutableDictionary*)dict setObject:@1 forKey:@"1"];
}

I think the true purpose of the Apple's note quoted in the question is that this code could easily lead to crash. And the problem here lies in toll-free bridging with CoreFoundation. Lets consider in more details 4 variants:

NSDictionary* dict = [NSDictionary new];
NSMutableDictionary* dict = [NSMutableDictionary new];
CFDictionaryRef dict = CFDictionaryCreate(kCFAllocatorDefault, NULL, NULL, 0, &kCFCopyStringDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
CFMutableDictionaryRef dict = CFDictionaryCreateMutable(kCFAllocatorDefault, 0, &kCFCopyStringDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);

Indeed, in ALL 4 variants the true class of the dict will be __NSCFDictionary. And all 4 variants will pass the test in the first code snippet. But in 2 cases (NSDictionary and CFDictionaryRef declarations) we will crash with log something like that:

* Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '-[__NSCFDictionary setObject:forKey:]: mutating method sent to immutable object'

So, things getting a little bit clearer. In 2 cases we are allowed to modify object, and in 2 cases are not. It depends on creation function, and probably mutability state is tracked by __NSCFDictionary object itself.

But why do we use the same class for mutable and immutable objects? Possible answer - because of C language limitations (and CoreFoundation is a C API, as we know). What problem do we have in C? The declarations of mutable and immutable dictionary types should reflect the following: CFMutableDictionaryRef type is a subtype of CFDictionaryRef. But C has no mechanisms for this. But we want to be able to pass CFMutableDictionary object in function expecting CFDictionary object, and preferably without compiler emitting annoying warnings. What we have to do?

Lets have a look at the following CoreFoundation type declarations:

typedef const struct __CFDictionary * CFDictionaryRef;
typedef struct __CFDictionary * CFMutableDictionaryRef;

As we can see here, CFDictionary and CFMutableDictionary are represented by the same type, and differ only in the const modifier. So, here start troubles.

The same generally applies to NSArray too, but the situation is a little bit more complicated. When you create NSArray or NSMutableArray directly, you will get some special classes (__NSArrayI and __NSArrayM respectively). For this classes crash in not reproduced. But when you create CFArray or CFMutableArray, the things remain the same. So be careful!

Answer 3

This is a strange warning in the Apple docs. It's like saying: "be careful of this function, because if you use it with other broken code, it won't work." But you can say that with anything.

If the design follows the substitution principle, which it should, then isKindOfClass will work. (wikipedia: Liskov Substitution Principle)

If some code violates the principle, by returning an instance of an NSMutableArray subclass that doesn't respond to the addObject: and other NSMutableArray methods, then that code has a problem... unless it's just a small-scale temporary hack...

Answer 4

The warning in the documentation uses the NSMutableArray example. Suppose some developer uses NSMutableArray as base class for his own implementation of a new kind of array CoolFunctioningArray. This CoolFunctioningArray by design is not mutable. However, isKindOfClass will return YES to isKindOfClass:[NSMutableArray class], which is true, but by design is not.

isKindOfClass: will return YES if the receiver somewhere inherits from the class passed as argument. isMemberOfClass: will return YES only if the receiver is an instance of the class passed as argument only, i.e. not including subclasses.

Generally isKindOfClass: is not safe to use to test for membership. If an instance returns YES for isKindOfClass:[NSString class], you know only that it will respond to all methods defined in the NSString class, but you will not know for sure what the implementation of those methods might do. Someone might have subclassed NSString to raise an exception for the length method.

I think you could use isKindOfClass: for this kind of testing, especially if you're working with your own code which you (as a good Samaritan) designed in such a way it will respond in a way we all expect it to (e.g. the length method of an NSString subclass to return the length of the string it represents instead of raising an exception). If you're using a lot of external libraries of weird developers (such as the developer of the CoolFunctioningArray, which should be shot) you should use the isKindOfClass method with caution, and preferably use the isMemberOfClass: method (possibly multiple times to test membership of a group of classes).