Re: Hiding superclass methods
Re: Hiding superclass methods
- Subject: Re: Hiding superclass methods
- From: email@hidden
- Date: Mon, 13 May 2002 08:36:58 -0700
Brock Brandenberg wrote:
|So, bringing a nib file to life is
|basically like me bringing an encoded and archived stream of objects to
|life that I might have created by writing custom data out to a file. I
|assume this is a better understanding?
That's it exactly; it's just IB writing the data out, not you.
|If my understanding is now
|correct, I would describe it as a a forked path with two starting points
|and one ending point. One starting point represents archived object data
|in a file (nib or custom user data), while the other starting point
|represents a new object being declared and initialized at runtime. The
|archived data path must go through a series of operations where the
|archived stream of data is read in, unarchived and decoded requiring
|coder initializers (or the underhanded key/value coding methods that
|Glen refers to) to process the data. The other path goes through
|designated initalizers like init: or initWithFrame: instead. Along each
|path, there are a number of "progress reports" like windowWillLoad:,
|windowDidLoad: or awakeFromNib: that let the developer know what stage
|of initialization the object is at. Knowing what is and what is not
|initialized at each stage is they key to knowing what you can do with an
|object and when you can do it.
Again, it sounds like you have it nailed. (The one nit I'd pick here is that key-value coding isn't particularly "underhanded", since it is documented as a standard feature of the Cocoa framework. In using the word, I was thinking more of IB and NSBundle taking advantage of secret, Apple-only knowledge of the innards of the system.)
Also, I'd say "what state of *construction* the object is at", since initialization is but one stage of construction, one with a specific meaning in Cocoa. (That's what started the whole discussion, after all: when does initialization take place?)
|My confusion was with how the initialization was happening. Did
|Cocoa use the key/value coding to secretly stuff values into memory, did
|the initWithCoder: method get called, or did the initWithFrame: method
|called? In essence, I wasn't sure what branch of the forked path I was
|on.
This is a common problem with the Cocoa documentation: it tends to assume you know things you may not actually know, because you haven't followed the "correct" path through the documents.
|So far, all of my custom views have behaved as I have expected. When I
|instantiate a custom view in the content view of a window or in one of
|it's subviews (like an NSTabView), my initWithFrame:, the designated
|initializer is being called reliably.
According to Erik, custom views from IB are special-cased in the NSBundle code, which would explain why initializers are being called for them, even when no others are being called.
Glen Fisher
_______________________________________________
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.