FROM : Jens Alfke
DATE : Thu Apr 03 21:08:26 2008
On 3 Apr '08, at 10:58 AM, Rob Napier wrote:
> Apple reserves the use of leading underscores for it's own use:
> While they append the phrase "especially in methods," they do mean
> for everything, and you can collide with them if you name your own
> identifiers (including instance variables) with leading underscores.
This issue came up several times while I was at Apple. The most recent
consensus (involving members of the Cocoa and compiler groups) was
that "_" prefixes for ivar names are mostly harmless, though they
should be avoided in method names. The reason is that ivar names are
less dynamic. If in the next OS release a system superclass of your
class adds an ivar with the same name, it's not a binary compatibility
problem (your class will continue to work, because its machine code
references the ivar as a numeric offset into the instance data, not by
name.) Whereas if a superclass adds a _method_ with the same name as
yours, all hell may break loose because your method will get called
instead.
Now, your code will break when you try to recompile it using the new
headers, because the compiler will complain about the ivar name
conflict. But then you just rename your ivar. It's a less serious
problem because it doesn't break any copies of the app that are out in
the field.
> 1. Leading underscores really will cause you to collide with Apple
> and it really did blow up in my face.
Was it with a method or an ivar name?
> 3. XCode 3 now provides good color coding to distinguish ivars from
> local vars.
I should try turning that specific color code on. I turned off all the
new Xcode 3 color coding because there were too many different colors
and it made the code look garish.
> 4. And besides, if you would use accessors properly, ivars should
> very seldom show up in your code so you shouldn't have confusion
> (this being the cause of #2 above).
I don't use accessors properly, then. ;) Method calls are so expensive
compared to ivar accesses that I don't use them for accessing instance
data, unless the accessor is nontrivial or the setter call is needed
to trigger KV notifications. (Also, I generally don't declare
properties for internal state that isn't part of the class's public
API.)
—Jens
DATE : Thu Apr 03 21:08:26 2008
On 3 Apr '08, at 10:58 AM, Rob Napier wrote:
> Apple reserves the use of leading underscores for it's own use:
> While they append the phrase "especially in methods," they do mean
> for everything, and you can collide with them if you name your own
> identifiers (including instance variables) with leading underscores.
This issue came up several times while I was at Apple. The most recent
consensus (involving members of the Cocoa and compiler groups) was
that "_" prefixes for ivar names are mostly harmless, though they
should be avoided in method names. The reason is that ivar names are
less dynamic. If in the next OS release a system superclass of your
class adds an ivar with the same name, it's not a binary compatibility
problem (your class will continue to work, because its machine code
references the ivar as a numeric offset into the instance data, not by
name.) Whereas if a superclass adds a _method_ with the same name as
yours, all hell may break loose because your method will get called
instead.
Now, your code will break when you try to recompile it using the new
headers, because the compiler will complain about the ivar name
conflict. But then you just rename your ivar. It's a less serious
problem because it doesn't break any copies of the app that are out in
the field.
> 1. Leading underscores really will cause you to collide with Apple
> and it really did blow up in my face.
Was it with a method or an ivar name?
> 3. XCode 3 now provides good color coding to distinguish ivars from
> local vars.
I should try turning that specific color code on. I turned off all the
new Xcode 3 color coding because there were too many different colors
and it made the code look garish.
> 4. And besides, if you would use accessors properly, ivars should
> very seldom show up in your code so you shouldn't have confusion
> (this being the cause of #2 above).
I don't use accessors properly, then. ;) Method calls are so expensive
compared to ivar accesses that I don't use them for accessing instance
data, unless the accessor is nontrivial or the setter call is needed
to trigger KV notifications. (Also, I generally don't declare
properties for internal state that isn't part of the class's public
API.)
—Jens






Cocoa mail archive

