Re: Stupid objective-c question
Re: Stupid objective-c question
- Subject: Re: Stupid objective-c question
- From: Quincey Morris <email@hidden>
- Date: Wed, 21 Sep 2016 20:33:52 -0700
- Feedback-id: 167118m:167118agrif8a:167118sS5zSm_QeE:SMTPCORP
On Sep 21, 2016, at 19:00 , Doug Hill <email@hidden> wrote:
>
> Just to be clear, the original question was specifically about comparing an Objective-C string literal. For this case, you definitely want to use -[NSString isEqualToString:]
Actually, no. A couple of similar comments in this thread have slightly missed the point about the original question.
The “cleverness” of that original approach was that the contents of the string really had nothing to do with anything. As long as the string being used for the current observer scenario was different from strings being used by other scenarios, the pointers to the string would be different, and every context would be different.
You could as easily have used (void*)1, (void*)2, (void*)3, etc in the various places in your app, but using meaningful strings instead is a fairly easy way of not mixing the pointers up.
Thus, there was never any intent to compare string values, just pointers, and that’s what made the ‘==‘ comparison crash-proof.
It wouldn’t be *illogical* to use string value comparisons instead, except that then, yes, you’d have to code around the cases where the context is not a pointer to a NSString object.
> As to the context type, I would be interested to know of cases where the observer doesn't have control over the context. My understanding is that the context is something that the observer sets itself when calling addObserver, and it is passed back to itself in the above method call. So the observer should know what kind of entity the context is, and can determine the best way to compare this value.
If you were the sole author of all observations in your app, you wouldn’t absolutely need a context parameter at all, since you can identify the observation** from the object and keypath. But you’re not.
The observer doesn’t have control over the context when the superclass or a subclass also does observations, and those other classes aren’t written as part of the project. For example, a view controller is a class that’s often going to want to observe things, but NSViewController may itself be observing things too, possible some of the same things. That’s one reason why the observer method must always call super for notifications that it cannot recognize *specifically* as resulting from observations it *specifically* added.
** Except in the case where observations from various sources are funneled through a common observer method, which doesn’t happen a lot, but does happen.
_______________________________________________
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