tags:

views:

57

answers:

2
@interface SomeClass : NSObject
{
}
@end

@implementation SomeClass
-(void) awesomeMethod600
{
}
@end

No error, and awesomeMethod600 works.

+6  A: 

The method declarations in the class interfaces are there for the compiler (to suppress warnings), since method lookup in Objective-C is done at runtime, and not compile time.

Perspx
For the compiler to do what with? There must be some difference when I omit them. Is it so it can throw warnings if I supply arguments against the definition? Can it generate faster code?Oh, you edited it.
Halpanger900
The compiler will check whether the methods you call are declared in any class interfaces that it knows about. If it can't find them it will emit a warning, but this is not necessarily an error as the actual lookup for that method call is done at runtime by the Objective-C runtime, and the method may not actually be in place at compile time (you can do stuff with the Objective-C runtime methods such as dynamically adding methods to classes at runtime, for instance).
Perspx
A: 

Perspx is right.

Try building this in XCode:

@implementation SomeClass
-(void)awesomeMethod {
    [self notAwesomeMethod];
}    

-(void)notAwesomeMethod {}
@end

You should see a warning that says 'SomeClass' may not respond to '-notAwesomeMethod'. Try inverting the order of the method definitions... no error since notAwesomeMethod is now already defined, and thus the compiler knows about it. Class interfaces do this upfront.

This is also nice behavior because you can choose to only publicize the class's public interface, and keep any internal private methods out of the .h file.

Amit
It's also kind of NOT nice behavior because then if someone learns about your private methods, they ARE in fact available, you just get warnings...
Brian Postow