Re: *Really* Understanding Cocoa
Re: *Really* Understanding Cocoa
- Subject: Re: *Really* Understanding Cocoa
- From: Mike Ferris <email@hidden>
- Date: Sat, 28 Dec 2002 10:21:13 -0800
A few things on this topic...
First, nibs. There's nothing magical about nibs. Nib files are
basically object archives (created with NSArchiver).
The archives contain all the objects that you create in IB, the windows
and widgets and menus, stuff you "instantiate" in the main nib windows,
etc.
The archive also contains "connection" objects. These are simply
objects that represent the connections in the nib. When the nib is
loaded, all the objects are unarchived. Then the unarchived connection
objects are asked to establish their connections, and after that, they
are released (they do not stick around after loading).
Some objects in a nib are represented by stand-in objects. When you
instantiate an object that you have defined but that is not available,
one of these stand-in objects represents it, and when the nib is
loaded, stand-ins are given a chance to replace themselves with an
instance of the real class they are supposed to be. One special object
that has a stand-in is the File's Owner object. This one is special
since the stand-in does not create a real object to replace it.
Instead the object is expected to already exist before the nib loads
and a pointer to it gets passed in to the nib loading mechanism. When
the File's Owner stand-in is encountered (in connection source or
destination references, for example), the real object that was passed
in is substituted.
That's really pretty much all there is to it. You can learn a lot
about how IB works by looking at the headers in the AppKit.framework
that start with NSNib... and also by looking at the headers in the
InterfaceBuilder.framework.
As for Objective-C, it was mentioned earlier that Objective-C is just
preprocessing on C. This is not really correct. Very early
implementations of the language were done, CFront-style, purely as
preprocessor transformations that resulted in pure C, but like modern
C++, modern Objective-C uses a true compiler.
It is still true that, in the end, Objective-C objects are structs, as
are Objective-C classes (which are themselves objects, of course). It
is also still true that an Objective-C message is transformed by the
compiler into a call to one of the messenger functions (objc_msgSend()
and friends). Also, methods are ultimately functions that always have
two initial, hidden, arguments: self and _cmd (_cmd is the selector of
the message that invoked the method and you can mention it in your
method bodies just as you can mention self).
As for *really* understanding Cocoa, in general, understanding exactly
how it is built on top of C is interesting and, for advanced purposes,
sometimes useful, but I would concentrate first on understanding some
of the underlying design patterns of Cocoa before you worry too much
about the specific low-level mechanisms. I think advanced Cocoa folks
are distinguished more because they have deep understandings of things
like
- NSResponder and the responder chain
- How responders relate to event handling and action dispatch
- The target/action pattern generally
- How delegation is used throughout the kits
- Objective-C's object model, the concreteness of its class
objects, and semantically how method dispatch works
- The model-view-controller pattern (not a Cocoa invention) and how
it takes form in Cocoa
- The document architecture and how it fits in with app design
- etc...
I learned Cocoa a long time ago, and although I worked on the Cocoa
team for many years, I first learned it from outside. The original
asker of this question sounds like he has the same sort of learning
style as me (he mentioned that he learned C best from K&R), and so I'll
tell you how I learned:
- I bought a cube (a black one ;-) back when I was in college
- I printed all the AppKit reference documentation (there was no
Foundation or Cocoa in those days... and I had to walk to school in the
snow every morning, uphill, both ways ;-)
- I read the entire set of class references, twice
The first time through there was a lot that did not click. But the
second time I understood more and began to connect things together in
my mind. All during this time I was playing around with programming as
well. After the second reading, and a few months practice with little
apps, I knew quite a bit.
Note that different folks have different learning styles. I go for
reference more than expository, tutorial style of teaching. Not
everyone will agree that slogging through the reference is the way to
start.
Mike
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.