Re: half-initialized objects during decoding (Re: Persistance)
Re: half-initialized objects during decoding (Re: Persistance)
- Subject: Re: half-initialized objects during decoding (Re: Persistance)
- From: Chris Kane <email@hidden>
- Date: Fri, 12 Oct 2001 13:12:16 -0700
On Friday, October 12, 2001, at 02:52 AM, Marco Scheurer wrote:
On Thursday, October 11, 2001, at 11:18 pm, Chris Kane wrote:
On Thursday, October 11, 2001, at 05:47 AM, Marco Scheurer wrote:
On Wed, 10 Oct 2001 13:21:01 -0700
Chris Kane <email@hidden> wrote:
The 'half-initialized object' problems I was referring to
I describe below. [...]
It seems to me that you can force yourself into the same
situation in other cases:
[...]
This is true. However, it's more common to be receiving
half-initialized objects back from the unarchiver than to get them
passed in as parameters in the ordinary course of executing the
program.
Why?
Because you're creating a cyclic object graph with many objects
simultaneously in a partially initialized state and setting up
references to other objects which normally aren't setup by
initialization. Create an NSView. After initWithFrame:, there is no
superview (still nil). But initWithCoder: on an NSView does initialize
the superview. Often initialization of an object is just part of the
story, and the object is subsequently modified to the desired
state/behavior. -initWithCoder: sets all that same stuff up in one
method.
And, none of this discussion addresses the fact that although
-initWithCoder: and -awakeAfterUsingCoder: return id, and in theory
allow you to return a different instance, in practice you may well
break references [...]
Replacement can also be done in other init methods, so again the
problem is general.
But in the case of initialization, you have one object which is
receiving a reference to the new object (and after the object is done
initializing you may hand it out many places), not potentially many
objects receiving it simultaneously, as in unarchiving (where many
things may request the partially initialized object from the coder).
Also it is a little more obvious that if you pass in "self" to another
object's initWithFoo: method in your init method, that destroying and
recreating self after that point might be the cause of your trouble.
Chris Kane
Cocoa Framework, Apple