I've always avoided using setters in init methods for exactly the
problem you've run into. A setter's behavior can depend on an object's
state, and by definition, the object's state is not really properly
setup *during* init.
_murat
On Apr 14, 2010, at 6:23 PM, Graham Cox wrote:
Hi all,
Got a slightly awkward problem I'm trying to find a good solution to.
I have a number of objects forming a class hierarchy where e.g. C
subclasses B which subclasses A. A has a 'locked' property which
locks it preventing changes to several other properties. B and C add
further properties some of which also check 'locked' in their
setters and become no-ops if locked is true.
When objects are dearchived, 'locked' is one of the dearchived
properties of A. But when B and C properties are subsequently
dearchived, if locked was YES, then many of these dearchived
properties, which are set through the relevant setters, are ignored.
Disaster ensues.
I can see a number of solutions:
A. When checking for locked in a setter, do something like:
if( locked && !currentlyDearchiving )
return;
But that needs lots of changes and some hackery to flag when
dearchiving is in progress.
B. For each implementation of -initWithCoder:, save the locked
state, set it to NO, dearchive, then restore the saved lock state.
That's slightly better, but still requires that all subclasses
remember to do this and is a biggish change to the code. I'd prefer
a way to handle this entirely in the base class, A.
So I'm wondering if I can use -awakeAfterUsingCoder:. Is it safe to
ask the coder to decode a value at that time? Since it runs after
all subclasses have been initedWithCoder, it ought to be the right
time to finally set the true state of the lock. I have misgivings
however that this is not its intended purpose.
If that's not allowed or would be bad for other reasons, is there a
way to defer it somehow, for example by posting a -
performAfterDelay on self to set the lock state - that would only
run after all dearchiving completed I believe.
Or something else?
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
