ximalaya

Encountering selectors, I found it not very clear, and the scattered introductions found online were also not systematic, so I decided to translate it myself to deepen my impression. The original text comes from the official API documentation under Selectors.

Selectors

In OC, selectors have two meanings.

1. When a selector is used in the source code to point to an object, the selector can simply refer to the name of this method.

2. A unique identifier is generated during code compilation, and the selector can also refer to that identifier.

The compiled type of selectors is SEL. All methods with the same name have the same selector. For a specific object (object), you can use the selector to call its methods. This provides the basis for the target-action design pattern in Cocoa (note: this part is explained at the end of this API).

Methods and Selectors

To improve efficiency, a complete ASCII name is not used as a method's selector in the compiled code. Instead, the compiler writes the name of each method into a table and pairs it with a unique identifier, which represents a specific method during runtime. The runtime system ensures that each identifier is unique: no two selectors are the same, and all methods with the same name have the same selector.

SEL and @selector

After compilation, a selector is assigned to a special type—SEL to distinguish it from other types. A valid selector will never be 0. You must let the system assign a SEL identifier to the method; arbitrarily assigned identifiers are invalid.

You should use the @selector() directive to pass the method name to the compiled selector, rather than using the full name of a method directly. For example, the following method can obtain the selector for setWidth:height: and assign it to the setWidthHeight variable:

SEL setWidthHeight;

setWidthHeight = @selector(setWidth:height:);

The most efficient way is to call the @selector() directive at compile time to assign a value to the SEL variable. However, in some cases, you may need to convert a string to a selector at runtime. You can use the NSSelectorFromString function to accomplish this:

setWidthHeight = NSSelectorFromString(aBuffer);

Reverse conversion is also possible. The NSStringFromSelector function can return the name of a method for a given selector:

NSString *method;

method = NSStringFromSelector(setWidthHeight);

Methods and Selectors

A selector can identify a method name after compilation, but it does not implement the method (not method implementations). For example, for a class, its display method has the same selector as other classes that also define a display method. This is essential for dynamic binding and polymorphism, as it allows you to send the same method to receivers of different classes. If every executing method had a selector, then sending this message would be no different from calling a function callback.

Class methods and instance methods with the same name are assigned the same selector, but since they belong to different domains, there will be no confusion between the two. A class can define a display method, in addition to an instance method.

Method Return and Parameter Types

The messaging routine can only access method entities (method implementation) through selectors, so it treats all methods with the same selector alike. The messaging routine can determine a method's return type and the data types of parameters through the selector. Therefore, unless the message is sent to a statically typed receiver, it requires that all instances of methods with the same name have the same return type and parameter types (the reason that statically typed receivers are an exception to this rule is that the compiler can understand the method entity from the class type).

Although class methods and instance methods with the same name are represented by the same selector, they can have different parameter types and return types.

Varying the Message at Runtime

The methods performSelector:, performSelector:withObject:, and performSelector:withObject:withObject: defined in the NSObject protocol use SEL identifiers as their initialization parameters. All three of these methods (note: I am curious why there are three, but the original text states three...) directly map to the messaging function. For example:

[friend performSelector: @selector(gossipAbout:)

                    withObject: aNeighbor];

This is equivalent to

[friend gossipAbout:aNeighbor];

These methods make it possible to change the message at runtime, just as you can change the object receiving the message. Variable names can be used in both halves of a message expression:

id   helper = getTheReceiver();

SEL  request = getTheSelector();

[helper performSelector:request];

In this example, the receiver helper is selected at runtime (through a hypothetical getTheReceiver function), and the method receiver is also required to execute request at runtime (also through a hypothetical getTheSelector function).

Note： The performSelector: method and its other companion methods return an object of type id, and if the currently executing method returns a different type, it should be converted to the appropriate type. (However, conversion does not apply to all types; the method should return a pointer or a pointer-compatible type.)

The Target-Action Design Pattern