FWIW, it’s currently an implementation detail that SELs do map into the global
address space in a way that doesn’t collide with anything else; but
technically, they are in their own address space and the system could map them
otherwise in a manner that does have collisions with other stuff.
In practice, I don’t think that will ever happen, because a) too much existing
code makes the assumption that a SEL is de-referenceable or otherwise depends
on this implementation detail; and b) we have 64-bit addressing, so we’re not
going to run out of address space such that making that change would be
advantageous.
> On Sep 26, 2016, at 6:17 PM, 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).
>
> So your code would become:
>
> if (context == @selector(mediaLibraryLoaded))
> {
> // …
>
> Or in Swift:
>
> if context == Selector("mediaLibraryLoaded")
> {
> // …
> (Swift's `Selector.init(_ str:String)` implementation
> <https://github.com/apple/swift/blob/master/stdlib/public/SDK/ObjectiveC/ObjectiveC.swift#L98
>
> <https://github.com/apple/swift/blob/master/stdlib/public/SDK/ObjectiveC/ObjectiveC.swift#L98>>
> just calls `sel_registerName` and (curiously) treats the returned pointer as
> a C-string.)
>
> Again, this is a blatant mis-use of the Objective-C API… but it is also a
> built-in compiler-optimized guaranteed-interned string, it won't cause issues
> when comparing to other arbitrary `void *`s, and the usage in Swift is almost
> identical to Objective-C.
>
>
> ----
>
>
> 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.
> 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.
>
> — Slipp
>
_______________________________________________
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
