On Sun, Jan 11, 2009 at 10:08 AM, glenn andreas <gandr...@mac.com> wrote: > > On Jan 10, 2009, at 11:48 PM, Michael Ash wrote: >> >> Except that if Apple renames one of their ivars to match the name of >> one of your subclass's ivars.... nothing happens. You don't crash, you >> don't misbehave. Everything continues on like usual. >> >> Unlike methods, ivars are *not* looked up by name, but rather by offset. >> > > Not true under 64 bit Objective-C 2.0 (nor the iPhone's 32 bit Objective-C > 2.0) which do not use an offset. > > And under those "modern" platforms, Apple doesn't even have to rename an > ivar - they can freely add new ivars to the base class, which increases the > chance of this collision (instead of just being limited to the rename of an > existing reserved ivar). > > The question, of course, is what happens when a super class in a framework > adds an ivar whose name collides with an existing subclass's ivar is > probably a question for Greg Parker... If the ivar "key" is based on the > ivar name + class where the compiler saw the ivar was declared, everything > is good. If it is just ivar name, problems.
A quick bit of testing reveals that the linker symbol looks like this: _OBJC_IVAR_$_MyClass.myClassIvar And so there will be no problem with matching names in the class hierarchy. > Perhaps this discussion should be taken to the Objective-C mailing list. I think it fits well here, given that much of the discussion is based around recommendations for names in Cocoa programs which wouldn't necessarily hold for non-Cocoa ObjC programs. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
