Where are Objective-C selectors registered/stored?

Question

I don't quite get the Objective-C selectors. The problem is: Where are Objective-C selectors stored ?

How do Objective-C Compiler and Runtime System work, so that they convert the method names into SEL ?

Answer 1

Selectors are "interned" (uniquified) strings. The runtime maintains a pool of interned strings (selectors). If you want to intern a string, you call either the sel_getUid() or the sel_registerName() runtime function with a C string, and it returns an opaque handle of type SEL (the selector). If the string has already been interned before, this selector is guaranteed to be equal to the previous one. Conversely, from a selector you can get the string back using sel_getName(). In Cocoa you would use NSSelectorFromString() and NSStringFromSelector(), which operate on NSString objects, instead of using the above low-level runtime functions.

Most of the time, you will not be doing conversion between strings and selectors in the middle of your program. Instead, the selector will have already been hard-coded at compile-time. When you do a method call like [foo something: bar], it is compiled down into something like objc_msgSend(foo, @selector(something:), bar), and the selector literal like @selector(something:) will be compiled into a reference into the binary's selector table generated by the compiler, similar to with global variables. When a module is linked, its selector table is merged with the main program's selector table to guarantee the uniqueness of selectors.

Answer 2

Have a look at Apples explanation:

A selector is the name used to select a method to execute for an object, or the unique identifier that replaces the name when the source code is compiled. A selector by itself doesn’t do anything. It simply identifies a method. The only thing that makes the selector method name different from a plain string is that the compiler makes sure that selectors are unique. What makes a selector useful is that (in conjunction with the runtime) it acts like a dynamic function pointer that, for a given name, automatically points to the implementation of a method appropriate for whichever class it’s used with. Suppose you had a selector for the method run, and classes Dog, Athlete, and ComputerSimulation (each of which implemented a method run). The selector could be used with an instance of each of the classes to invoke its run method—even though the implementation might be different for each.

If you have a look at @AntoniKedracki post there is a really good explanation about methods and selectors.

Just a short summary from the post:

Every objective-c method will be represented inside a struct in c. The struct looks like this:

struct objc_method {
    SEL method_name                                          
    char *method_types                                       
    IMP method_imp                                           
} 

So the selector will be created by C automatically from the method name and saved inside the SEL method_name. If you want to get access to the objc_method you should include the <objc/runtime.h>, than you will be able to use the runtime methods.

For more information have a look at the link in the other post.

Answer 3

The same question was bothering me too for a while. So I've looked into the runtime implementation. That's what I've found:

All the selectors are stored in a hash set. If you already have a registered selector, it will be returned by the objc runtime using c functions sel_getUid & sel_registerName, if not registered, it will be created by the same functions. Both of them have the same implementation & behavior, 'cause they are calling private function named __sel_registerName. Old runtime uses pointer to struct __objc_sel_set to store values.

struct __objc_sel_set {
uint32_t _count;            /* number of slots used */
uint32_t _capacity;         /* maximum number of used slots */
uint32_t _bucketsNum;       /* number of slots */
SEL *_buckets;              /* can be NULL if not allocated yet */
};

New runtime uses pointer to struct NXMapTable:

typedef struct _NXMapTable {
/* private data structure; may change */
const struct _NXMapTablePrototype   *prototype;
unsigned    count;
unsigned    nbBucketsMinusOne;
void    *buckets;
} NXMapTable OBJC_MAP_AVAILABILITY;

Hope this helps.