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 (Cocoa-dev@lists.apple.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

Reply via email to