Re: Observing with GC

FROM : Graham
DATE : Tue Feb 26 23:36:01 2008

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_removed>
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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/graham%
> 40ictinternational.com.au
>
> This email sent to <email_removed>