Re: Garbage collector vs variable lifetime

FROM : Charles Srstka
DATE : Mon Jun 09 18:37:35 2008

On Jun 9, 2008, at 2:56 AM, John Engelhart wrote:

> Well, in the case of your example, you have a bug: You have 
> statically typed the class to NSArray, not your subclass.  If one 
> applies the 'attribute only applies to the class it was specified 
> for' rule:
>
> By statically typing the class to NSArray, you have certified to the 
> compiler that no other object type will be received as an argument. 
> When you passed it an object of a different type, even a subclass, 
> you broke your promise to the compiler.


What on earth are you talking about? When you're working with 
NSArrays, you're *always* dealing with a subclass. You will *never* 
have an object that's just of class NSArray, because NSArray is a 
class cluster. When you initialize an NSArray, Foundation gives you 
whatever subclass of NSArray it figures is most suitable for whatever 
you're doing. This is even mentioned in the documentation for NSArray.

Let me show you an example:

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    NSArray *array = [NSArray arrayWithObjects:@"foo", @"bar", nil];

    NSLog(@"array is an %@", NSStringFromClass([array class]));

    [pool drain];
    return 0;
}

When run, this gives:

[Session started at 2008-06-09 11:22:30 -0500.]
2008-06-09 11:22:30.641 test[14449:10b] array is an NSCFArray

The Debugger has exited with status 0.

As you see, what I have is an instance of NSCFArray (a private 
subclass for which we have no headers), even though I initialized an 
NSArray. This happens with a lot of other Foundation objects too, like 
NSString (get yourself one of those, and you could end up with a 
NSConstantString, an NSCFString, an NSPathStore2, or who knows what 
else. The only guarantee you have is that the object will provide all 
the methods that the abstract superclass promises, but which 
particular subclass you're getting and what's under the hood, you 
can't know. Heck, the situation might even change, so that the NSArray 
or NSString subclass you get might be different in a later version of 
OS X than it is currently in 10.5.3. Class clusters are extremely 
common in the default Cocoa classes, and are a fairly common practice 
in general with Cocoa programming (my app, for one, uses class 
clusters).  So there's certainly no way a compiler should be able to 
tell what particular subclass of NSArray (or perhaps even a custom 
subclass that you defined) it's got just from looking at an NSArray, 
and certainly no one's promised any such thing to the compiler.

Charles