Re: Visualizing Cocoa
Re: Visualizing Cocoa
- Subject: Re: Visualizing Cocoa
- From: Scott <email@hidden>
- Date: Sat, 09 Jun 2001 12:14:55 -0700
On 6/9/01 4:45 AM, "John C. Randolph" <email@hidden> wrote:
>
..unless you've subclassed NSApplication, and NSApp is actually a member
>
of a different class.
True -- that's an advanced topic.
>
[snip]
>
>
No. NSApplication, like all Obj-C classes, is an instance of the
>
meta-class.
>
>
>it's no more an NSObject that it is an NSTextView.
>
>
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"
>
>
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)
John, thanks for the post!
In general, I was approaching it from a slightly higher level -- trying to
straddle the line of instance and abstraction, the event horizon, if you
will. And I think with that in mind, we agree on all points.
As such, for this example NSApp is an instance of NSApplication, not
NSResponder, even though it gets some of its functionality from NSResponder.
That's where the inheritance confusion comes in. The instance is still
NSApp which is an NSApplication object, not an NSResponder.
Yes, when it all gets resolved, the program counter runs through some code
from the NSResponder object, but it's from the responsibility level of NSApp
(NSApplication). It's the idea of an NSApplication object being in control
of that action, regardless of where the code comes from.
Brian - any of this make sense?
Scott
------
"...there's no such thing as a plain name..."
http://www.domainjane.com