Re: Observing with GC
Re: Observing with GC
- Subject: Re: Observing with GC
- From: Graham <email@hidden>
- Date: Wed, 27 Feb 2008 09:36:01 +1100
I hesitate to weigh in on an established thread, but I ran into this
myself a while back.
Isn't part of the purpose of the observer mechanism to allow
observees to proceed with their normal activities blissfully unaware
of any observers that might be looking at 'em? In which case they
won't be keeping track of their observers so have no easy way to tell
them to get lost when they are about to disappear.
Obviously one can design observees to keep a reference to their
observers, but if they need to do that they may as well message them
directly with state changes (though KVO as it stands is obviously
still more convenient).
I've probably misunderstood something about the design philosophy
behind KVO, but as everything is up to the observer to decide when to
safely start and stop observing, the possibility of the observee
being dealloced out from underneath the observer is a realistic
possibility that the current design doesn't handle very nicely.
Surely it would be more useful and easier to use if the pattern was
for an observer to observe an object until it decides to stop OR
UNTIL the observee goes away, whichever occurs first. I don't
understand why this second case has to cause an error, as it does now.
Perhaps someone better acquainted with the design can explain why
it's not done this way? Working around this one issue vastly
overcomplicates an observer/observee situation which to my mind makes
KVO less useful than it appears to be.
--------
S.O.S.
On 27/02/2008, at 2:51 AM, Sean McBride wrote:
On 2/26/08 12:01 AM, Quincey Morris said:
On Feb 25, 2008, at 21:08, Bill Bumgarner wrote:
In general, -finalize should not be used to manage scarce resource
nor muck around with the app's object graph, including tearing down
observations and the like.
I find it hard to see anything dangerous in the finalize strategy
used
in the above code, unless:
Don't forget that -finalize methods must be thread-safe. Your
example:
- (void) finalize {
if (observer)
[self removeObserver: observer forKeyPath: @"name"];
[super finalize];
}
Is removeObserver:forKeyPath: documented to be threadsafe? After a
quick search, I find it hard to tell.
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
40ictinternational.com.au
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden