Re: Required in .h
Re: Required in .h
- Subject: Re: Required in .h
- From: Ondra Cada <email@hidden>
- Date: Wed, 29 Aug 2001 11:39:54 +0200
Chris,
>
>>>>> Chris Gehlker (CG) wrote at Tue, 28 Aug 2001 20:53:03 -0700:
CG> >Can someone give me a hard and fast rule for this if such exists?
CG>
CG> The good practice rule is that every method and every function
That's very definitely not true. At the very least, with more complicated
classes one often needs internal methods, like
@implementation Q
...
-(void)_justToHaveMoreConvenientImplementation { ... };
...
-APImethodA { ... [self _justToHaveMoreConvenientImplementation]; }
-APImethodB { ... [self _justToHaveMoreConvenientImplementation]; }
-APImethodC { ... [self _justToHaveMoreConvenientImplementation]; }
...
@end
You don't want to have _justToHaveMoreConvenientImplementation in header.
CG> should be in a .h file. The ones Apple supplies are already in
CG> Cocoa.h so you don't
CG> need to mention them again in your own .h file.
Let's re-phrase it: Each method or function should be declared before used.
That means that internal methods/functions should be defined before first
usage (or declared at the top of .m file where they belong to), and external
ones should be declared in _SOME_ .h file -- be it the one of yours, or some
imported one.
CG> validateMenuItem: and awakeFromNib don't need to be in your .h file.
right, but still there are reasons to mention them: for methods where [super
xyz] is not a standard, a subclasser needs to know whether they are
implemented or not.
Yeah, you *can* let him to check always with respondsToSelector:, but that's
not polite ;)
CG> Of course, different methods with the same name are fine.
With some caveats if they happen to have return values/arguments of
different types. The compiler would warn, though, so problems are unlikely
(unless you ignore warnings, which is a quite bad thing to do).
CG> The other thing about .h files is that humans read them. Don't hesitate
CG> to include something that is not required by the language if it will make
CG> it more clear whether or not the compiler requires it. For example, if
CG> you override a method in a way that isn't obvious, declare it in the .h
CG> file of your descendent class and comment it.
Very very definitely! And if you _DON'T_ override it but change its
behaviour other way (which is possible thanks to eg. forwarding), don't
forget to add a comment to the header with a comprehensive description.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc