> On Sep 21, 2016, at 6:36 PM, Graham Cox <graham....@bigpond.com> wrote:
>> On 22 Sep 2016, at 10:40 AM, Quincey Morris
>> <quinceymor...@rivergatesoftware.com> wrote:
>> On Sep 21, 2016, at 17:01 , Graham Cox <graham....@bigpond.com> wrote:
>>> This should be: if([(NSString*)context
>> Actually, this is not a good idea either, because *other* observations —
>> ones you don’t control — might use a value that’s not an object, or not even
>> a valid pointer.
> Fair point.
> Which is yet another reason why void* is such a shitty concept. Apple could
> easily have insisted that parameter was id<NSObject> without any real
> problems, so void*… sheesh.
> So Gabriel’s alternative is basically to use a global address, as you
> otherwise suggested.
> void* tsk… *goes away muttering*
Just to be clear, the original question was specifically about comparing an
Objective-C string literal. For this case, you definitely want to use
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.
But hey, always check the documentation first. Here's a nice little tidbit from
"The address of a uniquely named static variable within your class makes a good
context. Contexts chosen in a similar manner in the super- or subclass will be
unlikely to overlap. You may choose a single context for the entire class and
rely on the key path string in the notification message to determine what
changed. Alternatively, you may create a distinct context for each observed key
path, which bypasses the need for string comparisons entirely, resulting in
more efficient notification parsing."
So, instead of using a string literal, create a static object and do pointer
comparisons is what Apple recommends.
Hope this helps.
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