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
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
