Are selectors in Objective-C just another way to send a message to an object?

Question

Are selectors in Objective-C just another way to send a message to an object? I really don't understand why or how to use them.

Answer 1

They aren’t another way to send a message to an object, they’re the only way. For example, in [myView setValue:@"foo"], setValue: is a selector. (Another, less convenient way of writing the same thing is objc_msgSend(myView, @selector(setValue:), @"foo").)

As Ian Henry says, you can use SEL values to choose a selector at runtime instead of compile time. This is a fundamental technique in Cocoa; user interfaces are generally connected to controllers using target/action bindings, where the target is an object and the action is a selector. Normally you set this up in a nib, but you can also do it in code:

[myButton setTarget:myController];
[myButton setAction:@selector(buttonClicked:)]; // Clicking the button will now call [myController buttonClick:myButton].

Answer 2

Selectors are usually used when you want to define a callback mechanism. The most common use case for selectors in Cocoa is with controls, such as buttons. A UIButton is very generic, and as such has no idea what should happen when the button is pressed. Before you can use one, you need to tell it what method should be run when the button is pressed. This is done as follows:

[myButton addTarget:self
             action:@selector(myButtonWasPressed)
   forControlEvents:UIControlEventTouchUpInside];

- (void)myButtonWasPressed {
    // Do something about it
}

Then, when the button is pressed, the button will call the selector on the target we passed it. With this mechanism, you don't need to subclass a button every time you want it to call some of your own code. Instead, UIButton itself has a generic mechanism for dispatching to any code you choose. (Okay, technically, it's the superclass UIControl that's providing the dispatch mechanism.)

Answer 3

You can store selectors as variables, and invoke them later or in a different context. For example you can tell an object to perform a selector at a particular time, or on a different thread. You can also choose which selector to perform based on data, which is how interface builder and core data do their thing.

Answer 4

At the most basic, yes, but you can change the message at runtime. For example:

SEL a = [selectorFactory getSelector];
[someOtherObject performSelector:a];

And then in selectorFactory.getSelector:

if(foo == 1)
    return @selector(thisSelector);
else
    return @selector(thatSelector);

Coming from C# or another similar language, you can use this to (loosely) simulate events much more easily than using NSNotifications. For example, you could make a button class with two ivars, target and selector, and have the button perform the selector on the target when it's clicked (for example).

There's a lot more to selectors than that, though. Read more about them here:

http://developer.apple.com/mac/library/documentation/cocoa/conceptual/objectivec/articles/ocSelectors.html

Answer 5

--From Apple Developer Library --

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.