Can someone explain the selectors according to this excerpt from the Apple Objective-C documentation?

Question

The relevant parts are highlighted in bold in the Apple Objective-C documentation:

Method return and parameter types

The messaging procedure has access only to the implementation of the method through the selector, so it processes all methods with the same selector like this. It detects the return type of the method and the data types of its parameters, from the selector. Therefore, with the exception of sent messages for statically typed receivers, dynamic binding requires all implementations of the same named methods to have the same return type and the same parameter types. (Statically typed receivers are an exception to this rule because the compiler can learn about an implementation method from a class type.)

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

I read this block again and again, but it seems I can’t get past what seems like a contradiction. First, he says that all implementations of the same named methods require the same return type and parameter types due to dynamic binding.

Since it applies to all methods with the same selector, does this mean that no matter how many different objects I have, if they all have an EatCake () method, then they will all use the same selector for EatCake ? If so, why should they have the same parameters and return type?

Then the next part says that although they are represented by the same selector, they can have different types of parameters and return types. So now I am completely confused, I thought it was just saying that it wasn’t.

I do not expect this to be a mistake, I expect I simply do not understand what the difference is between the two statements.

Can anyone clarify this for me?

Answer 1

It is not required that all methods with the same selector have the same parameters and return types. A selector is simply a name that identifies a method, without any of this information.

The problem is that the compiler needs to know what types of parameters and return data are when you call the method so that it can perform type checking for you. When the excerpt tells about dynamic receivers, we are talking about variables with type id and messages sent to the result of the method that returns id . Since this only tells the compiler that it is an object, but not the class, it cannot determine which class should be used to determine the parameters and return types. Thus, the only way he can know is to use all the parameters of this selector with the same parameters and return types.

The excerpt also explains that there is an exception for statically typed receivers, which means that you specified a specific class for your variable type, such as NSString *myString . Since the compiler knows that the object must be an NSString object, it knows to use this parameter and return types from this class, so it should not be the same for objects of another class.

All this has absolutely no effect on runtime. When you call a method, the runtime gets this actual class of objects and uses this to find the right implementation for the call. It does not perform type checking, so it doesn’t care what the types of parameters and returned data are.

Answer 2

Armed with the following links:

• Apple Docs: Selectors (original bold snippet quoted in question)
• Apple Docs: Enabling Static Behavior

and decoration of experiments, I came to the following unexpected (for me!) conclusion that there cannot be two methods with the same selector, but with different types / return types. And this is true all over the world.

The second statement is that which is surprising. We know that there can be no method overloading in Objective-C ("A single selector for a given class can have only one type signature."), Therefore it is executed locally. But also there cannot be two different unrelated classes with the same selector, but different:

• the arguments
• return types

I have a suspicious suspicion that my conclusion may not be entirely correct, so if you know better, please tell me.