• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Objective-C Instance Variable Names
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Objective-C Instance Variable Names


  • Subject: Re: Objective-C Instance Variable Names
  • From: Mario Gajardo Tassara <email@hidden>
  • Date: Fri, 4 Apr 2008 20:15:51 -0400


El 03-04-2008, a las 16:19, email@hidden escribió:

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1875 bytes
Desc: not available
Url : http://lists.apple.com/pipermail/cocoa-dev/attachments/20080403/a3d0ef05/smime.bin


I just name the all my instance variables "the_instance_var_" , and the local ones "theLocalVar", this keep me well informed about if X var is instance or local :).


Mario Gajardo Tassara email@hidden



_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Objective-C Instance Variable Names
      • From: "Dennis C. De Mars" <email@hidden>
  • Prev by Date: Re: core data - beyond the simple example
  • Next by Date: Re: How do I embed a font in an app?
  • Previous by thread: Re: Objective-C Instance Variable Names
  • Next by thread: Re: Objective-C Instance Variable Names
  • Index(es):
    • Date
    • Thread