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.
Perhaps this discussion should be taken to the Objective-C mailing list.
Glenn Andreas gandr...@gandreas.com
<http://www.gandreas.com/> wicked fun!
quadrium2 | build, mutate, evolve, animate | images, textures,
fractals, art
_______________________________________________
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
