Stumped as to origin of methods


Hi All,

I may have a brain cloud: I am having difficulty understanding the origin of some of the methods used for observations
More specifically;

p. 153
-(void)startObservingPerson:(Person *) person
-(void)stopObservingPerson:(Person *) person

and p. 154
-(void)changeKeyPath:(NSString *)keyPath

We implement them, but where are they declared ?

Are Start(stop)Observing(YourClassNameGoesHere) one of those
key-coding mechanisms? Where in the documentation might they be explained ??



Hi Judy

By a coincidence, I have just come into this forum to ask this exact same question. I’m working through the chapter and can’t work out why they don’t need a declaration in the header file.

I would have guessed they were another example of KeyValue Coding, but the insertObject and removeObjectFromEmployeesAtIndex methods required a declaration in the header file and they were KeyValue codes.


Hi again,

I don’t know if this helps, but I’ve just written a small command line application that allowed me to call an undeclared method inside a class:

#import <Foundation/Foundation.h>

@interface TestMethod : NSObject

- (BOOL)testMe;

#import "TestMethod.h"

@implementation TestMethod

- (BOOL)returnYes
    return YES;

- (BOOL)testMe
    return [self returnYes];


This builds with no complaints. Only testMe is visible outside of the class and therefore it would appear that writing methods without a declaration is the equivalent of declaring a method as private in other C based languages such as Java and C#.

There is a caveat and that is that the method needs to be implemented in the class above any methods that wish to use it. In the book the instructions do say to add the startObservingPerson and stopObservingPerson methods near the top of the file - I guess that’s why.

Hopefully someone will be along to confirm or reject my theory. I didn’t think Objective-C had any concept of private methods, which I thought was odd, but if this is how it’s done then I’m happy with that. Hope this helps. :slight_smile:


Makes sense to me,
Thanks !



More on private methods:

So, my son got home from work, and I showed him your solution.
He agreed and suggested a method one can use to declare the private method (in the .m file) if you wish to
place it anywhere in the (.m file code) …i.e. before or after you use it.

#import “RMDocument.h”
#import “Person.h”

@interface RMDocument ()
-(void)startObservingPerson:(Person *)aPerson
-(void)stopObservingPerson:(Person *)aPerson;

@implementation RMDocument

this seems to work fine …
Also, he said you do it differently for plain C methods.

in the implementation file (.m), declare the method in the normal manner;
such as

@implementation RMDocument
void newMethod(int something);

then you can use it as a private method.
Pays to send kids to college :wink:



That’s good to know… thanks.

I come from a C++ and C# background and while a lot is familiar, some things like this aren’t (although the concept of declaring a method higher up the implementation file rings a bell and I think it may be how it is in the C language). To me it’s strange that Objective-C doesn’t properly support private and protected methods.

Well, between us we managed to answer our own question. We should get bonus points. :geek:

Good luck with the rest of the book!


Thanks for your reply ! it wasn’t until I looked at the “plain C” stuff again,
that I realized I wasn’t familiar with that syntax either !

I messed around with CodeWarior several years back in (I believe) C++, but became discouraged
when i tried to wade into doing event loops.

Then I changed to Real Basic - now Real Studio – for maybe too long.
Its good to get into XCode . I think its the best !



Thanks for all your post here guys (and ladies).
Of course you can always declare those methods (as I did, having not noticed the location advise)…

Objective C starts getting on my nerves…

to much guesswork involved… methods that get called automagically and we have to know the right name, methods that need no declaration at the .h files, but need to be on-top of the implementation… I’m wondering what other magic the next chapters of this book have…

Up to now, I would vote for Java if I could use it for Mac OSX…



You may be interested to know that the compiler with more recent versions of Xcode (4.3.x) no longer cares about the ordering of methods within the implementation (.m) file – it is smart enough to scan the entire file. The older behavior was a result, I believe, of Objective-C being an extension of C itself, and being particular about functions being defined before they are used is very C-like.

I hope that you’ll stick with Objective-C; its dynamic nature (which can be perceived as magic) allows you to do some things rather easily that end up being very inconvenient with statically typed languages. However, in the interests of completeness I should note that, yes, this dynamic nature can get you into trouble here and there. But I think it’s worth it. :slight_smile: