Re: Coding conventions
Re: Coding conventions
- Subject: Re: Coding conventions
- From: Jim Correia <email@hidden>
- Date: Mon, 29 Oct 2001 12:35:48 -0500
Bill Cheeseman wrote:
Apple reserves the leading underscore for its own private headers, to
help
avoid namespace conflicts (you wouldn't want to unknowingly override a
private Apple variable). Apple has specifically (but informally)
requested
that the rest of us not use leading underscores.
Bill, I read your comments in the Vermont recipes, and it seems that
they are restricted to private functions (though I read quickly, so I
may have missed it).
I want to understand why this is a problem. I think there are 3
separate problems here (correct me when I go astray).
1. Private Functions
2. Instance Variables
3. Methods/Messages/Selectors
1. Isn't this particular problem solved by 2-level name spaces in X?
2. Doesn't the compiler always sort this issue out for you (since it
needs to see the header in order to subclass, and when you do if you
create a new instance var with the same name, it complains).
@interface Base : NSObject
{
@private
int _instance1;
int _instanceOther;
}
@end
@interface Leaf : Base
{
@private
void *_instance1;
int _instance2;
}
main.m:30: duplicate member `_instance1'
3. So now we have messages. If you write the following
@interface Base : NSObject
{
}
- (void)doSomething:(NSString *)aString;
- (void)doSomethingElse:(NSString *)aString;
@end
@implementation Base
- (void)doSomething:(NSString *)aString
{
NSLog(@"%s", [aString cString]);
}
- (void)doSomethingElse:(NSString *)aString
{
[self doSomething: aString];
}
@end
@interface Leaf : Base
{
}
- (void)doSomething:(NSArray *)anArray;
@end
@implementation Leaf
- (void)doSomething:(NSArray *)anArray
{
NSLog(@"%@", anArray);
}
@end
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
Leaf *leaf = [[Leaf alloc] init];
[leaf doSomethingElse: @"foobar"];
[leaf doSomething: @"foobar"];
[leaf release];
[pool release];
return 0;
}
The compiler will warn you about the call from main to doSomething
because of incompatible pointer types, but you won't be warned about the
[self doSomething: aString] in Base.
Am I correct so far?
So in this situation if we avoid the _ mess, we can avoid conflicts with
Apple private messages whose definitions are hidden so the compiler
can't complain about them, but you'll have to exercise the same level of
caution with your own code, with Apple public messages, etc., because
even when the compiler can see the message declaration it can't always
warn you about this conflict.
Trying to understand the problem in its completeness,
Jim