I yowled (nicely, I hope :-) at him for that; because of this:
"Avoid the use of the underscore character as a prefix meaning private, especially in methods. Apple reserves the use of this convention. Use by third parties could result in name-space collisions; they might unwittingly override an existing private method with one of their own, with disastrous consequences. See �Private Methods� for suggestions on conventions to follow for private API."
Scott and I both agree that Apple's recommendation to name private components with a prefix (like this: XY_doSomethingAmazing) is really ugly to read. My solution is to, whenever possible, avoid having true private methods -- instead, I prefer to use protected semantics, where those methods are declared in the header and documented as being available only for use by subclasses (typically, I can design a class such that what those methods are doing is abstract enough to keep subclasses from getting too tightly bound to the implementation details of the superclass).
For true private ivars (and yes, I do know that this makes you grimace, Scott :-) where by that I mean an ivar that should not be available to subclasses at all, I declare them @private and do not create accessors for them (figuring that a true private ivar is so close to the implementation of the class that it doesn't need the encapsulation that accessors provide, and accepting the slight trade-off in maintainability should I ever need to attach functionality to the ivar accesses), and if a subclass does use the same name, the compiler will throw an error.
The proper solution, of course, would be for GCC & the runtime to add true private namespaces for ivars and methods; perhaps by some simple name-mangling scheme like prepending the class path (delimited by periods or some other character that you can't type in a method/ivar declaration) to the token string as soon as the compiler recognizes it as a private item...
by britt — Nov 04
I yowled (nicely, I hope :-) at him for that; because of this:
"Avoid the use of the underscore character as a prefix meaning private, especially in methods. Apple reserves the use of this convention. Use by third parties could result in name-space collisions; they might unwittingly override an existing private method with one of their own, with disastrous consequences. See �Private Methods� for suggestions on conventions to follow for private API."
found here.
and this:
"Don�t use the underscore character as a prefix for your private methods. Apple reserves this convention."
found here.
Scott and I both agree that Apple's recommendation to name private components with a prefix (like this: XY_doSomethingAmazing) is really ugly to read. My solution is to, whenever possible, avoid having true private methods -- instead, I prefer to use protected semantics, where those methods are declared in the header and documented as being available only for use by subclasses (typically, I can design a class such that what those methods are doing is abstract enough to keep subclasses from getting too tightly bound to the implementation details of the superclass).
For true private ivars (and yes, I do know that this makes you grimace, Scott :-) where by that I mean an ivar that should not be available to subclasses at all, I declare them @private and do not create accessors for them (figuring that a true private ivar is so close to the implementation of the class that it doesn't need the encapsulation that accessors provide, and accepting the slight trade-off in maintainability should I ever need to attach functionality to the ivar accesses), and if a subclass does use the same name, the compiler will throw an error.
The proper solution, of course, would be for GCC & the runtime to add true private namespaces for ivars and methods; perhaps by some simple name-mangling scheme like prepending the class path (delimited by periods or some other character that you can't type in a method/ivar declaration) to the token string as soon as the compiler recognizes it as a private item...