Re: Visualizing Cocoa
Re: Visualizing Cocoa
- Subject: Re: Visualizing Cocoa
- From: "John C. Randolph" <email@hidden>
- Date: Sat, 9 Jun 2001 04:45:26 -0700
On Saturday, June 9, 2001, at 02:20 AM, Scott wrote:
It's the idea of "who reigns supreme? Who's in charge here?" and the
answer
(in Cocoa) is ultimately NSApplication.
..unless you've subclassed NSApplication, and NSApp is actually a member
of a different class.
I tend to only think about class
hierarchies when I'm designing the objects for my app and then never
think
about them again because it has so little to do with the flow of the
application.
Another way I look at it is: NSApplication is an object of the type
NSApplication.
No. NSApplication, like all Obj-C classes, is an instance of the
meta-class. NSApp is a global value, which will almost always be a
pointer to an instance of NSApplication or a subclass thereof.
I.E. even though it inherits some of the same functionality
of, say, NSObject, it's no more an NSObject that it is an NSTextView.
This
was an abstraction that took me some time to grasp, but it cuts down on
the
amount of things you need to remember about NSApplication, for example.
This is incorrect. NSApplication is every bit an NSObject, since
NSObject is one of its ancestors. It's perfectly legal (although it may
in some cases be nonsensical) to send NSApplication any message that an
NSObject can take in your application.
Inheritance is cool, but it gets in the way.
???
Another example, when you tell
your NSApplication to "becomeFirstResponder" (a method it inherits from
NSResponder) it doesn't pass control to an NSResponder object. That
NSApplication object itself handles the call.
Again, this is incorrect. NSApplication descends from NSResponder, so
when NSApp becomes the first responder, there is indeed an NSResponder
object in control. (That is, NSApp itself)
-jcr
[Objc retain];