On Sep 21, 2016, at 19:00 , Doug Hill <cocoa...@breaqz.com> 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 (Cocoaemail@example.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:
This email sent to arch...@mail-archive.com