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

Question

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

Answer 1

They have no other way to send a message to an object, but this is the only way. For example, in [myView setValue:@"foo"] , setValue: is a selector. (Another, less convenient way to write the same thing: objc_msgSend(myView, @selector(setValue:), @"foo") .)

As Jan Henry says, you can use SEL values ​​to select a selector at runtime instead of compile time. This is the fundamental method in Cocoa; user interfaces usually connect to controllers using target / action bindings, where the target is the object and the action is the selector. Usually you install this at the tip, but you can also do this in code:

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

Answer 2

Selectors are commonly 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 general, and therefore has no idea what should happen when a button is clicked. Before you can use it, you need to specify which method to run when the button is clicked. 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 that we passed. With this mechanism, you don’t need to subclass a button every time you want it to call part of your own code. Instead, UIButton itself has a common mechanism for sending to any code you UIButton . (Well, technically this is the UIControl superclass that provides a submit mechanism.)

Answer 3

You can store selectors as variables and call them later or in a different context. For example, you can tell an object to execute a selector at a specific time or in another thread. You can also choose which selector to perform based on the data, how the interface creator and main data do their job.

Answer 4

At its 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 (free) to simulate events much easier than using NSNotification s. For example, you can make a button class with two ivars, target and selector , and when you press a button on the selector, press the select button (for example).

However, for selectors this is much more. Read more about them here:

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

Answer 5

- from the Apple Developers Library -

A selector is the name used to select the method to execute on the object, or a unique identifier that replaces the name when compiling the source code. The selector itself does nothing. It simply identifies the method. The only thing that makes the name of the selection method different from a simple string is that the compiler guarantees the uniqueness of the selectors. What makes the selector useful is that (in combination with the runtime) it acts as a pointer to a dynamic function, which for a given name automatically indicates an implementation of a method suitable for any class with which it was associated. Suppose you had a selector to run the method and the Dog, Athlete, and ComputerSimulation classes (each of which implemented the method). The selector can be used with an instance of each of the classes to invoke the method of its launch, even if the implementation may be different for each.