On 10 Jan, 2009, at 3:28 AM, Adam Foltzer wrote:
I stand corrected; I've seen this many times before, and have never
had
problems. I'm guessing it's one of those patterns that causes
problems under
specific circumstances?
To give some concrete examples where calling a setter from -init or -
dealloc may cause problems:
1) The setter may post a notification
If you call the setter from -init or from -dealloc then observers
which are already registered with the notification center at that time
will be invoked when the object is either only partially constructed
or partially deconstructed. However, the observers do not know that
and naturally make the assumption that they are invoked with a fully
constructed object. Thus an observer may end up accessing a property
which is not valid at this time or they may invoke a method on the
partially constructed/deconstructed object which may result in a crash
if we are lucky, or may corrupt data if we are not so lucky (the
former case is "more" lucky because there is a greater chance that we
will notice it in the testing phase of the project).
2) The setter may store the previous property value in an undo stack
- which is usually not what we want when we are constructing or
deconstructing an object.
3) Assuming that passing nil to a setter clears out the underlying
property is problematic,
since it may not be so simple in actual practice. The setter may for
example store the old property value in some sort of global cache
which would imply that calling [self setFoo: nil] from -dealloc will
leak memory. The reason for such a caching strategy could be because
actual practice has shown that -setFoo: gets called with a small set
of different values and the internal property representation requires
some additional computational overhead (aka, the internal property
representation differs from what you pass into the method but is
dependent on the passed in value).
Another thing to keep in mind is that what exactly passing nil to a
setter means is not clear in the general case. Some setters may
explicitly disallow the passing of nil as it makes semantically no
sense for them (and would in fact imply that there is somewhere a bug
in the caller), others may interpret it as "set the property to its
documented default value" which brings us back to the leaking problem.
4) You never know what a subclass is going to do to your setter
A subclass may overwrite one of the setters which you call in -init or
-deallc and may turn it from a "save" setter implementation (one which
basically just sets the underlying instance variable and does nothing
else) into an "unsave" implementation which posts a notification, adds
undo/redo support, etc.
Regards,
Dietmar Planitzer
_______________________________________________
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
