On 19/08/2008, at 10:16 AM, Graham Cox wrote:
The point is that observees should not know or care about their observers. Once you stop trying to let observees control their observers your problems will ease considerably. Instead, observers are entirely responsible for their own actions - observing an object and unobserving it later. The main problem usually is the need to unobserve before the observee is deallocated "out from under it". There's no one true way to do this, but just organise your code so that the need doesn't arise. For example a controller that deletes an object can send a "about to delete x" message before it does so that any observers can disconnect from x, or the deletion of an object is handled through a wrapper method that removes the observers. Typically if you look at where and why you are observing an object, a simple approach to managing its observers is usually straightforward. I must admit though that getting it right can be tricky especially if you're trying to fit KVO into an existing model that wasn't built with it in mind.
I have quite a few observers that persist as long as the document is open and one thing I've found useful is to post a notification when the document is going away, which tells all the observers that are instantiated in that document to remove themselves as observers.
I agree that this is an annoying problem and I wish that Apple had implemented this with weak references as they have with NotificationCenter observers. Maybe they have for Snow Leopard, I haven't checked.
-- Rob Keniger _______________________________________________ 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]
