On 27 Sep 2016, at 02:17, Slipp Douglas Thompson <apple+cocoa-...@slippyd.com> wrote: > > I'm just going to throw this out there as a solution, not because I recommend > this approach (it's API misuse after all) but because it would work. > > Instead of using an `NSString *` you could use a `SEL` (AKA `struct > objc_selector *`) since SELs are guaranteed to be unique for each given > string they represent (within a process; AFAIR).
Indeed, they’re interned by the Objective-C runtime. However, this is a blessing and a curse; it’s a blessing in that comparing with a selector will be fast, you can use “==“ to do the comparison, and the resulting code will be easy to read. It’s a curse in that it means you must choose a unique selector. So @selector(mediaLibraryLoaded) is unlikely to be a good choice; something like @selector(com:mycompany:mediaLibraryLoaded) might be. > My 2¢: I'm still in favor of making all usages of `context` in your app > `NSObject *`s or `nil` because sometimes you do want to store an > `NSDictionary *` or other data in `context` that's meant to be read later. The context value is not retained (and there’s no obvious guarantee about when you can expect that it won’t be used again; assuming that you won’t be called with your context value immediately after deregistering for KVO notifications will probably result in the creation of a subtle race condition). Also, other code might result in you receiving a non-nil pointer that doesn’t point to an object. The safest way really is to take the address of a static variable in your code and use that; there are, as you rightly suggest, alternative addresses you could use (a selector, or a function address would both work, as would a dynamically allocated address, provided you stored it somewhere). > But if you're stuck with using other libs that don't use `NSObject *`s or > `nil`, or if you really want to ensure your code won't crash because its > making assumptions about what's in the `context` your code registered, then > I acknowledge your case. Key point: I personally wouldn't use the `SEL` > approach, but still. The SEL approach is better, modulo the requirement for the name to be unique. But the idiom used by most of us is to take the address of a static variable, and I’d recommend sticking to that. The important point in all of this, though, is that you can’t safely dereference the context pointer, because you don’t know what it is. You may *think* you do, because you’ve supplied *one* possible value for it, but other code that you don’t control can supply other non-nil values and they will point at whatever that code chose to point them at, which probably wasn’t the same as your choice. Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ 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
