On Aug 18, 2008, at 12:49 PM, Negm-Awad Amin wrote:
Am Mo,18.08.2008 um 18:18 schrieb Andy Lee:
-- but in this case I think -dealloc is not only okay, but
sometimes the only correct place to unregister a notification.
Suppose an invariant of your design is that an object should
receive notifications as long as, and only as long as, the object
exists. If you unregister too soon, you may have an "alive" object
that fails to get a notification.
This is little bit a circular argumentation: I need it the whole
lifetime, so i manage it the whole lifetime. Why do you need it
until the instance becomes deconstructed?
It's only circular in that I specifically selected a class of
situations where it makes the most sense. :)
I think this is the right pattern:
1. Construct and init the object
2. Let them work (register observations, handling threads, $whatever
… )
3. Stop them
4. Deconstruct them
So there are 4 steps, not 2.
This pattern is fine and necessary in many cases, but there are also
plenty of cases where it is not viable. For example, it may not be
clear when the object can "stop" listening for notifications. It may
literally be when all other objects are done with it, i.e., when its
retain count goes to zero, and in a dynamic system you may have no way
of knowing which will be the last object to release your object.
IMO imposing a start-stop paradigm on every class that wants to
register interest in notifications -- and engineering every class so
that your object can't possibly be released until it is "stopped" --
is just as much a design error as putting functional work in -
dealloc. I would encourage you to reconsider.
In the cases where you do have a start-stop paradigm, you should put a
"stop" in -dealloc anyway, as Michael argued.
I think it's okay to unregister in -dealloc because conceptually
it's related to releasing your ivars. You're explicitly dissolving
a relationship between the object being dealloced and some other
object -- a relationship you have to manually manage in the absence
of garbage collection.
In this case it seems to be ok. Maybe this is the reason for the
weak reference.
The weak reference is to avoid retain cycles (the same reason why
delegates are not retained). With GC turned on, retain cycles are not
a problem so you don't have to worry about weak references to self,
just as you don't have to bother releasing strong references to
ivars. In the absence of GC, you have to break connections manually,
and that's all this is. In fact, you should also break delegate
connections to self in the same place, for the same reason. (Hm, I'm
not sure whether I'm doing this in my own code -- I'd better check.)
You mentioned KVO in another reply. I haven't used KVO, so I'd be
interested if anyone has a response to your counterexample.
--Andy
_______________________________________________
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 [EMAIL PROTECTED]
