> On Sep 21, 2016, at 8:33 PM, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> On Sep 21, 2016, at 19:00 , Doug Hill <cocoa...@breaqz.com
> <mailto: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.
I believe the original question was why you can compare a string literal to
another object pointer using the == operator and it somehow works. The contents
of the string in this case would be very important because the compiler does
some magic to make duplicates of strings all have the same address. As was
mentioned, this is a quirk of string pooling/merging by the compiler and that
it might happen in some cases but maybe not in others. For example, I think you
can control this behavior in GCC and LLVM with a compiler setting. Just to make
it clear, CLang calls this undefined behavior:
NSString *foo = @"xyz123";
if( foo == @"xyz123" )
NSLog(@"YES");
warning: direct comparison of a string literal has undefined behavior
[-Wobjc-string-compare]
Again, in general (i.e. not just for observing scenarios) you probably
shouldn’t rely on identical strings, especially literals.
But as we’ve now verified from Apple documentation, comparing to a static
variable address is the way to handle the context parameter in key path
observation, so we shouldn’t be involving literals.
>> 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.
This makes sense. I’m glad I’m getting this figured out after all these years.
:)
Doug Hill
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
