Re: Class vs +class: Cocoa/Obj-C design question
Re: Class vs +class: Cocoa/Obj-C design question
- Subject: Re: Class vs +class: Cocoa/Obj-C design question
- From: Chris Ryland <email@hidden>
- Date: Mon, 15 Oct 2007 22:47:54 -0400
On Oct 13, 2007, at 3:56 PM, Bill Bumgarner wrote:
On Oct 13, 2007, at 12:17 PM, Chris Ryland wrote:
Can I ask perhaps a "list in the mists of time" language/library
question? (Or perhaps a dumb question--forgive me if so.)
Why can't a class name (e.g., NSObject) stand for itself in
general--i.e., why isn't NSObject == [NSObject class] the way
+class is defined now?
In theory, NSObject is a class object, and [NSObject class] should
be its metaclass.
Why this breakdown in what otherwise is a very clean language/
library design?
Classes can be every bit as dynamic as instances.
Through posing or any of a number of other mechanisms, the 'isa'
pointer of a class -- the thing returned by [NSObject class] -- can
easily change at runtime.
Thus, you should always use [ClassName class] or NSClassFromString
(@"ClassName") to grab a reference to the class as doing so will
always return the correct result regardless of what might have been
dynamically loaded or modified since the original link.
Bill--
I appreciate that *instance* classes may change dynamically (e.g.,
NSArray *array = [[NSArray alloc] init] may end up with array not
being an actual NSArray instance but some subclass in the cluster),
but are there real-life cases where a class itself (e.g., literally
NSObject) can change its class? Where the literal expression
[NSObject class] wouldn't be NSObject itself?
I would think the more appropriate way to work around any language
oddities with type names, etc. would be [NSObject self] to use a
message to get at the class itself, rather than [NSObject class],
which should, in theory, return the class of NSObject, i.e., its
metaclass.
Forgive me for pushing back (and I know you would know this, if
anyone in the world would), but I'm still wondering (and perhaps
still confused).
Thanks &
Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden