• 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: Jens Alfke <email@hidden>
  • Date: Mon, 7 Apr 2008 07:39:58 -0700


On 7 Apr '08, at 1:45 AM, Kyle Sluder wrote:

Then I'm sure you're very familiar with the fragile base class
problem.  Just don't do it.

Ivar name conflicts don't have anything to do with the FBC problem, not in compiled languages. The FBC problem arises when the size of a superclass changes, which changes the offsets of the instance variables of subclasses, breaking already-compiled code in subclasses that accesses ivars by offset.


What this means is that, if your superclass adds an ivar, your code is broken and has to be recompiled. That's true regardless of what the superclass ivar is named. If it does happen to match your name, then when you recompile your code you'll get a compile error and can use the handy Refactor command to rename your ivar.

(In practice, Apple will never add ivars to their classes, for exactly that reason. That's why they all have a placeholder ivar named "_extra" or something like that — if needed, that can be used to point to an auxiliary struct.)

Now, the 64-bit runtime eliminates the FBC by looking up ivar offsets dynamically. But IIRC, it doesn't use the names of the ivars when doing so (it just looks up the total sizes of instance data of each superclass.) So again, name conflicts aren't an issue at runtime.

It's bad form because eventually it will
break.  And then you'll spend ages in the debugger trying to figure
out just who assigned to "your" ivar.

No, the breakage doesn't occur at runtime, rather at compile time. And it results in a simple compile error that's very easy to fix.


—Jens

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

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: glenn andreas <email@hidden>
References: 
 >Objective-C Instance Variable Names (From: Richard Somers <email@hidden>)
 >Re: Objective-C Instance Variable Names (From: Jens Alfke <email@hidden>)
 >Re: Objective-C Instance Variable Names (From: "John C. Randolph" <email@hidden>)
 >Re: Objective-C Instance Variable Names (From: Todd Blanchard <email@hidden>)
 >Re: Objective-C Instance Variable Names (From: "Kyle Sluder" <email@hidden>)

  • Prev by Date: Re: Objective-C Instance Variable Names
  • Next by Date: Re: Constraining a NSSlider to Certain Values
  • Previous by thread: Re: Objective-C Instance Variable Names
  • Next by thread: Re: Objective-C Instance Variable Names
  • Index(es):
    • Date
    • Thread