Re: Clarification on accessors? (was: Yet another memory management question)
Re: Clarification on accessors? (was: Yet another memory management question)
- Subject: Re: Clarification on accessors? (was: Yet another memory management question)
- From: Ben Trumbull <email@hidden>
- Date: Thu, 9 Jul 2009 14:29:24 -0700
-init and -dealloc are special in that the object is not in a
consistent
state during those methods (it either hasn't yet entered it's
"initial"
state or is transitioning out of its "final" state). If your
accessors rely
on the internal state of the object being "normal", they could blow
up when
called in these methods.
As Graham & Chris note, -init and -dealloc are special.
The problem is really larger than that, though. In Cocoa, most
setters are called upon the receiver by another object as public API
to change the receiver. The setters may have complex behaviors
associated with them, either directly or via KVO. Change tracking,
document dirtying, undo registration, recomputing derived values, etc.
But the receiver may also wish to express the notion of a private
change in state that does not do any of that. In this case, while an
ivar may change state in a literal sense, the class is not changing
state as defined by its public API. Perhaps the document remains
clean, perhaps there is no undo, or perhaps derived values are left
unchanged (typically because all the private state is being rolled
back together, so recomputing them is pointless)
You may need to distinguish between "privately restoring state" and
"publicly changing state"
Conflating the public accessors with "setting an ivar" during init or
dealloc is troublesome and inflexible. As with "privately restoring
state", "constructing state" and "destructing state" are just not the
same as "publicly changing state". While it will work for many simple
projects, as behavior is added to classes, it tends to scale poorly.
Considering init & dealloc blessed (or cursed) allows for maximum
flexibility for accessors and subclasses while minimizing bizarre bugs
due to objects being in a partially constructed state. It's not a
law, but it is the most pragmatic rule of thumb.
There are a great many kinds of bugs that can sprout from partially
constructed objects. Subclasses may access uninitialized state,
setters may register the object in a global table before init is
finished creating a multi-threading bug, setters may allocate more
memory during dealloc, etc
It may be that under certain circumstances (dictionary storage,
synthesized properties on 10.5, etc) that you must use an accessor
method even in init & dealloc. That requires more care, is more error
prone, and less flexible. In particular, additional behavior should
not be adorned to the accessor, and the accessor must never leak
knowledge of the receiver to a third party during init or dealloc.
Basically, these accessors must be very very boring.
- Ben
_______________________________________________
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:
This email sent to email@hidden