Re: Stupid objective-c question
Re: Stupid objective-c question
- Subject: Re: Stupid objective-c question
- From: Doug Hill <email@hidden>
- Date: Wed, 21 Sep 2016 21:10:18 -0700
> On Sep 21, 2016, at 8:33 PM, Quincey Morris <email@hidden> wrote:
>
> On Sep 21, 2016, at 19:00 , Doug Hill <email@hidden <mailto: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.
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 (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