CODEWITHSUNDEEP
iosobjective-c
Rainer Schwarze
Rainer Schwarze

Reputation: 4755

Objective-C method signatures: Parameter types can differ between declaration and implementation?

I can declare a method in the @interface having parameter type NSString*:

- (id) initWithString:(NSString*)str;

while in the implementation it is NSNumber*:

- (id) initWithString:(NSNumber*)str

For a full example, see the code below. When calling [Work test] the output is a.x = Hi, so the passed-in NSString* went through and one can see that the "correct" initWithString method was called.

Why is this code accepted by the compiler?

Can I make the compiler complain when parameter types differ?

Citing from Apple's documentation Defining Classes :

The only requirement is that the signature matches, which means you must keep the name of the method as well as the parameter and return types exactly the same.

My test code:

@interface ClassA : NSObject

@property (strong, nonatomic) NSNumber *x;

- (id) initWithString:(NSString*)str;
- (void) feed:(NSString*)str;

@end

@implementation ClassA

- (id) initWithString:(NSNumber*)str
{
    self = [super init];
    if (self) {
        self.x = str;
    }
    return self;
}

- (void) feed:(NSNumber*)str
{
    self.x = str;
}

@end


@implementation Work

+ (void) test
{
    ClassA *a = [[ClassA alloc] initWithString:@"Hi"];
    NSLog(@"a.x = %@", a.x);
}

@end

I added the feed method to see, whether it is "special" to init-like methods, but the compiler doesn't complain either. (Ran this on Yosemite / Xcode 6.4 / iOS8.4 Simulator.)

PS: If I didn't use the right terms, please correct me :-)

Upvotes: 4

Views: 1179

Answers (3)

Nikolai Ruhe
Nikolai Ruhe

Reputation: 81868

Can I make the compiler complain when parameter types differ?

There's a warning for this which you can activate by including the following line in the header:

#pragma clang diagnostic error "-Wmethod-signatures"

You can also put -Wmethod-signatures into the project's "Other Warning Flags" Xcode build setting to activate this for the whole project.

I don't really understand why Apple is so hesitant to activate helpful warnings like this by default.

My standard pattern on virtually every project is to put -Weverything in "Other Warning Flags". This activates all warnings clang has to offer.

Since there are some warnings that are a little too pedantic or don't serve my coding style, I individually deactivate unwanted warning types as they pop up.

Upvotes: 5

TotoroTotoro
TotoroTotoro

Reputation: 17622

In Objective-C a method is defined as a string (known as a selector) in the form of doSomethingWithParam:anotherParam:. Or in your case it will be initWithString:. Note there's no parameter types in these strings. One side-effect of defining methods like this is that Objective-C, unlike Java or C++ doesn't allow overloading operators by just changing the parameter type. Another side-effect is the behavior you observed.

EDIT: Additionally, it appears that the compiler does not look at the implementation at all when checking method calls, just the interface. Proof: declare a method in a header, don't specify any implementation for that method, and call this method from your code. This will compile just fine, but of course you'll get an "unrecognized selector" exception when you run this code.

It'd be great if someone could provide a nice explanation of the default compiler behavior.

Upvotes: 0

danh
danh

Reputation: 62676

I'm surprised by the quote you found stating that param and return types matter to the uniqueness of the method signature. Re-reading, I think you found a bug in the doc.

Defining a parameter type in the interface will generate a warning for callers that do not pass that type (or cast the parameter to that type), no matter the implementation. Changing the parameter type in the implementation is exactly like casting the parameter within the method. Nothing wrong with that, not even a cause for warning. So long as the different type shares methods (polymorphic or inherited) with the declared type.

In other words, restating by example...

The following will cause a compiler error, proving that distinct param types offers no distinction to the compiler (same is true for return type)...

// .h
- (void)foo:(NSString *)str;

// .m
- (void)foo:(NSString *)str {    
    NSLog(@"called foo %@", [str class]);
}

- (void)foo:(NSNumber *)str {    <----- duplicate declaration error
}

The following will cause no compiler warnings, errors or runtime errors...

// .h
- (void)foo:(NSString *)str;

// .m
- (void)foo:(NSNumber *)str {
    // everything implements 'class', so no problem here
    NSLog(@"called foo %@", [str class]);
}

The following is exactly like the previous example in every respect...

// .h
- (void)foo:(NSString *)str;

// .m
- (void)foo:(NSString *)str {
    NSNumber *number = (NSNumber *)str;
    NSLog(@"called foo %@", [number class]);
}

The following will cause no warnings, but will generate a runtime error because we are abusing the cast by invoking a method that the passed type doesn't implement (presuming the caller calls with a string as the interface indicates)...

// .h
- (void)foo:(NSString *)str;

// .m
- (void)foo:(NSNumber *)str {
    NSLog(@"does str equal 2? %d", [str isEqualToNumber:@2]); <--- crash!
}

All of the foregoing matches intuition and behavior in practice, just not that passage in the doc. Interesting find!

Upvotes: 0

Related Questions