On Thu, Feb 21, 2008 at 1:46 PM, Kyle Sluder
<email@hidden> wrote:
> On Thu, Feb 21, 2008 at 2:41 PM, Ken Ferry <email@hidden> wrote:
> > What's guaranteed is that all init methods on a class will funnel into
> > one of the designated init methods. A subclasser should always
> > override all designated initializers of the superclass (if he needs to
> > do work at initialization time). Then you're guaranteed to have your
> > setup performed no matter how the object is created.
>
> What I'm saying is that I'm not sure this is guaranteed to be true for
> unarchiving. Since (with rare exception) any override of a designated
> initializer is supposed to call super's implementation, it would be
> very easy to introduce improper behavior by calling -[NSView
> initWithFrame:] at design time, archiving the object graph into the
> nib, and then calling -[MyView initWithFrame:], which then invokes
> -[NSView initWithFrame:], when unarchiving the view from the nib.
>
> I think the Apple docs are pretty clear that there is no guarantee
> whatsoever that any initializer will be called on your objects when
> unarchiving from a nib. The nib unarchiving mechanism doesn't really
> care about your setters, getters, and initializers. It restores
> whatever state it knew about when it archived the object, trusting you
> to implement -awakeFromNib if you need subclass-specific processing.
Hm, sorry if the docs confused you.. if you can point at the docs that
made you think this, it'd be great to have a bug.
All objects _do_ go through some init method, including those in a
nib, and every init method of a class is intended to call through to a
designated initializer. You can count on this. -awakeFromNib is
great for setup that really does have to do with a nib, but pure
initial object initialization is better done in an init method.
Otherwise, you risk that setup not getting done if your object is
created in a way that doesn't involve a nib. For example,
NSCollectionView and NSToolbar with both sometimes try to 'copy' view
hierarchies by encoding and decoding to a keyed archive. (That kind
of copying is really hard to get right, by the way.)
As Ondra described, there is complexity in exactly which init method
is used for what object that you see in IB, but if you override all of
the designated initializers then your code won't care which init
method actually gets called. It might be any of -init,
-initWithCoder:, or -initWithFrame:, depending. IB will also show a
few objects that are actually external to the nib, like the nib file's
owner and the shared NSApplication object. These few objects already
existed and were initialized before the nib was instantiated, so they
won't get an init method when the nib is coming up.
Ken Ferry
Cocoa Frameworks
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
This email sent to email@hidden
