Re: Required in .h
Re: Required in .h
- Subject: Re: Required in .h
- From: Chris Gehlker <email@hidden>
- Date: Tue, 28 Aug 2001 20:53:03 -0700
On 8/28/01 3:35 PM, "Stuppel, Searle @ San Diego Central"
<email@hidden> wrote:
>
What exactly is required in a .h file?
>
>
I know this is probably a basic question, but after a long time of messing
>
with it, my guess comes down to: Only stuff that other files need to be able
>
to "see".
>
>
In other words:
>
- (BOOL)validateMenuItem:(NSMenuItem *)anItem; is not needed in a .h
>
- (void)awakeFromNib; is not needed in a .h
>
>
Can someone give me a hard and fast rule for this if such exists?
The good practice rule is that every method and every function should be in
a .h file. The ones Apple supplies are already in Cocoa.h so you don't need
to mention them again in your own .h file. That's why validateMenuItem: and
awakeFromNib don't need to be in your .h file.
For backwards compatibility, C will do something called "Miranda
Prototypes". That means that if you define a function or a method in a .m
file before you refer to it the language will let you get away with a
warning. This is not a good idea. On a large project that evolves over time
it is too likely that a couple of different functions will get defined with
the same name in different .m files. This can lead to all kinds of
confusion.
Of course, different methods with the same name are fine.
The other thing about .h files is that humans read them. Don't hesitate to
include something that is not required by the language if it will make it
more clear whether or not the compiler requires it. For example, if you
override a method in a way that isn't obvious, declare it in the .h file of
your descendent class and comment it.
--
Adults are obsolete children.
-Dr. Seuss, humorist, illustrator, and author (1904-1991)