Re: Dependent values that are not iVars
Re: Dependent values that are not iVars
- Subject: Re: Dependent values that are not iVars
- From: Quincey Morris <email@hidden>
- Date: Fri, 18 Dec 2009 12:13:50 -0800
On Dec 18, 2009, at 11:18, Paul Bruneau wrote:
>> 2. Your observer method is stripped down, right? You are really using a unique value for the context parameter, right? It's not really safe to just not care.
>
> No, I'm not using context. My feeling was that since I am checking for the keypath, that is all I needed to care about. Can you elaborate about the unsafeness of that? Thank you.
Your code may not be the only place an observation was added. In particular, the superclass may have done so too. Therefore, you're supposed to invoke the super implementation of the observer method, but *only* if the observation is not one you registered. How do you know if it's one you registered? You have to use the context parameter to recognize your own registrations.
Some people use globally unique strings for the context. I tend to use the class:
[addObserver: ... forKeyPath: ... options: ... context: [MyClass class]];
(note that [self class] would be wrong, because subclasses need their own unique contexts too).
Incidentally, checking just the key path is a mistake too. You also need to check at least the class of the object passed to the observer method. In your original example, if the class with the dependent property ever tried to observe "overallWidth" on itself, things would be messed up because you'd have observations of two properties in different classes but with the same key funneling through the same observer method.
If this all sounds like a horrible defect in the the observer mechanism -- it is.
_______________________________________________
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