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 of class clusters, the object you get back may not always be the type you expected.

The documentation then proceeds to give an example of why you should never ask something like the following of an NSArray instance:

// DO NOT DO THIS!
if ([myArray isKindOfClass:[NSMutableArray class]])
{
    // Modify the object
}

Now to give an example of a different use, let's say I have an instance of NSObject where I would like to determine if I have an NSString or NSArray.

Both of these types are class clusters - but it seems from the documentation above that the danger lies in the answer to isKindOfClass: being too affirmative (answering YES sometimes when you really do not have a mutable array) whereas asking a question about simple membership in a cluster would still be valid.

An example:

NSObject *originalValue;

// originalValue gets set to some instance

if ( [originalValue isKindOfClass:[NSString class]] )
   // Do something with string

Is this assumption correct? Is it really safe to use isKindOfClass: against class cluster instances to determine membership? I'm specifically interested in the answer for the omnipresent NSString, NSArray and NSDictionary but I'd be interested to know if it's generalizable.

Answer 1

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).

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

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 4

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...