On Aug 20, 2008, at 07:58, Joan Lluch (casa) wrote:

I understand what is your preferred approach, which it is also what I would do. I can add to it that I even thought that you *have to* *always* unregister the observers when you have done with them. This is obviously true in RC environment, but this is apparently not true in the case of GC. This is the part I don't get. I would appreciate if someone would clarify it for me.

This thread has wandered off into confusion because it mixes up 2 unrelated kinds of "observer". These two mechanisms have absolutely nothing in common, except the word "observe".



Under GC, notification centers keep weak references to their notification observers. As Michael pointed out, these references are automatically zeroed when the observer goes away, so the notification center can detect the situation and clean itself up accordingly. This does *not* mean that an observer can't be removed until it goes through its finalize -- removeObserver: can of course be called at any time.

In a non-GC app, you always have to call removeObserver:, and the observer's dealloc is a reasonable place to ensure that it's been done before the observer goes away. Under GC, there's no equivalent of dealloc, but happily there's no need to ensure that it's been done.



Under GC, KVO keeps a strong reference to the KVO observer in (or, rather, in a private constructed-on-the-fly sort-of-subclass of) the observed object. If the observer goes away, the strong reference is left dangling and will usually result in an exception. With luck, Apple will decide to change the KVO implementation sometime to keep weak references, so that such dangling references won't exist. If it makes the change, that also does not mean that an observer can't be removed except by being finalized -- removeObserver:forKeyPath: can of course be called at any time.

In a non-GC app, again, dealloc is a reasonable place to ensure that removeObserver:forKeyPath: has been called. Under GC (until Apple decides to change KVO), there's no way to *ensure* that the observation has been "cancelled" before the observer goes away. You have to rely on someone calling it earlier, and it's sometimes a significant programming headache to make sure this gets done properly.

_______________________________________________

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]

Reply via email to