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

From the Apple Objective-C documentation, bolded relevant parts:

Method Return and Parameter Types

The messaging routine has access to method implementations only through selectors, so it treats all methods with the same selector alike. It discovers the return type of a method, and the data types of its parameters, from the selector. Therefore, except for messages sent to statically typed receivers, dynamic binding requires all implementations of identically 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 the method implementation from the class type.)

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

I've read this block over and over but I can't seem to get past what seems to be a contradiction. First it says that all implementations of identically named methods are required to have the same return type and parameter types because of dynamic binding.

Since it treats all methods with the same selector alike, does this mean that no matter how many different objects I have, if they all have a EatCake() method then they will all share the same selector for EatCake? If so, then why must they have the same parameters and return type?

Then in the next part it says though they are represented by the same selector, they can have dif开发者_如何学Pythonferent parameter types and return types. So now I'm totally confused, I thought it just said this was not the case.

I do not expect that this is a mistake, I expect that I am simply not understanding what the difference is between these two statements.

Can anyone clear this up for me?

---

It is not required that all methods with the same selector have the same parameter and return types. The selector is simply a name which identifies the method, without any of that information attached.

The problem is that the compiler has to know what the parameter and return types are when you call a method so that it can perform type checking for you. When the excerpt talks about dynamic receivers, it is talking about variables with a type of id and messages sent to the result of a method which returns id. Since this only tells the compiler that it is an object, but not what class it is, it cannot determine which class should be used to determine the parameter and return types. Therefore, the only way it can know is if all uses of that selector have the same parameter and return types.

The excerpt also explains that the exception is for statically typed receivers, which means you specified a certain 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 the parameter and return types from that class, so it doesn't need to be the same for objects of a different class.

This all has absolutely no effect on the runtime. When you call a method, the runtime gets that objects actual class and uses that to find the proper implementation to call. It performs no type checking, so it doesn't care what the parameter and return types are.

---

Armed with the following references:

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

and a garnishing of experimentation, I have come to the following surprising (to me!) conclusion that there can be no two methods with the exact same selector but different parameter/return types. And this holds true globally.

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

• arguments
• return types

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