tags:

views:

28

answers:

1

Having just spent ages debugging this, I'm keen to understand what exactly is going on!

In a very contrived example, let's say we have two objects, Object1 has this method:

- (void) testMethod:(NSString *)testString

Object 2 has this method:

- (void) testMethod:(NSArray *)testArray

Then, back in Object1, there's the following code in a method:

NSArray *myArray = [[NSArray alloc] init];    
[[[Object2 alloc] init] testMethod:myArray];

When I compile, Xcode gives a warning:

Incompatible pointer types sending 'NSArray *' to parameter of type 'NSString *'

I believe I'm right in saying the warning occurs because I never actually specify the type of Object2. Explicitly casting the object to Object2 fixes it, but my questions are thus:

  1. When calling testMethod on Object2, why is it using the method from Object1, when the objects are nothing to do with each other?
  2. Why does the warning vanish if I move #import "Object2.h" into Object1.h instead of Object1.m?

Thank you!

+4  A: 

When there are two methods with the same selector but different signatures, the compiler must decide which signature to use at compile time — because the signature can affect the code generated. Unfortunately, the compiler is deeply stupid, and the only way it has to tell which signature to use is by checking the static type of the receiver. In this case, both alloc and init return id, so the compiler has no information whatsoever with which it can decide what kind of object you're sending this message to. So it basically does this to break the tie: It closes its eyes, spins around in a circle a bunch of times, and whichever signature it's pointing to when it stops, that's the one it uses. Then it checks your argument type against this stochastic signature, and if it guessed wrong, it thinks you've passed the wrong type.

The best solution is to avoid signature collisions — descriptive method names usually take care of this on their own, and adding more specificity to one or both selectors is often a good way to solve the problem you're encountering (e.g. make it testMethodWithName:(NSString *)name).

It's also a good idea to statically type things as far as possible. Normally this isn't a problem, because you'll want to assign the newly created object to a variable anyway. In a pinch, when it would just be awkward to assign the result of the method to a variable, you can also just cast the ambiguous part to the correct type, like [(Object2 *)[[Object2 alloc] init] testMethod:myArray].

Chuck
+1 especially for the descriptive method name advice
JeremyP
Thanks, is your spinning in a circle analogy basically saying Objective C's behaviour is just undefined when there isn't an explicit type cast? That would explain why moving the #import changed the behaviour.
Tom Gilder
@Tom Gilder: Yep. It isn't undefined behavior in the traditional C sense, but it isn't defined in any useful way either. That is why moving the import will make a difference even though there's no obvious reason why it would.
Chuck
Thank you Chuck, much appreciated.
Tom Gilder