views:

242

answers:

1

Recently while trying to answer a questions here, I ran some test code to see how Xcode/gdb reported the class of instances in class clusters. (see below) In the past, I've expected to see something like:

PrivateClusterClass:PublicSuperClass:NSObject

Such as this (which still returns as expected):

NSPathStore2:NSString:NSObject

... for a string created with +[NSString pathWithComponents:].

However, with NSSet and subclass the following code:

- (void)applicationDidFinishLaunching:(UIApplication *)application {    
    NSSet *s=[NSSet setWithObject:@"setWithObject"];
    NSMutableSet *m=[NSMutableSet setWithCapacity:1];
    [m addObject:@"Added String"];
    NSMutableSet *n = [[NSMutableSet alloc] initWithCapacity:1];
    [self showSuperClasses:s];
    [self showSuperClasses:m];
    [self showSuperClasses:n];
    [self showSuperClasses:@"Steve"];   
}

- (void) showSuperClasses:(id) anObject{
    Class cl = [anObject class];
    NSString *classDescription = [cl description];
    while ([cl superclass]) 
    {
        cl = [cl superclass];
        classDescription = [classDescription stringByAppendingFormat:@":%@", [cl description]];
    }
    NSLog(@"%@ classes=%@",[anObject class], classDescription);
}

... outputs:

// NSSet *s
NSCFSet classes=NSCFSet:NSMutableSet:NSSet:NSObject
//NSMutableSet *m
NSCFSet classes=NSCFSet:NSMutableSet:NSSet:NSObject
//NSMutableSet *n
NSCFSet classes=NSCFSet:NSMutableSet:NSSet:NSObject
// NSString @"Steve"
NSCFString classes=NSCFString:NSMutableString:NSString:NSObject

The debugger shows the same class for all Set instances. I know that in the past the Set class cluster did not return like this.

  1. What has changed? (I suspect it is a change in the bridge from Core Foundation.)
  2. What class cluster report just a generic class e.g. NSCFSet and which report an actual subclass e.g. NSPathStore2?
  3. Most importantly, when debugging how do you determine the actual class of a NSSet cluster instance?
+2  A: 
  1. An implementation detail changed most likely related to the bridging to CF. If you look closely, you'll see that a bunch of the Objective-C implementation backing various Foundation classes can now be found in CoreFoundation.

  2. Another implementation detail. The implementation of the Foundation class clusters change -- sometimes greatly, sometimes subtly -- with each release of Mac OS X. The exact set of private classes related to said implementation is generally fallout from whatever particular set of requirements were needed to achieve a flexible and reasonably optimal solution while also preserving the API contract of the public facing classes.

  3. NSCFSet is the actual class. The features of the instances are determined by how you allocated it in the first place. There is no exposed way to determine if your set is mutable or immutable. This is actually on purpose; going down the path of writing a lot of code that changes behavior based on the mutability of a class cluster leads to madness.

bbum
That's pretty much what I thought. It can make debugging other people's code something of challenge when you're not sure they initialized things as they should.
TechZen