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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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 [EMAIL PROTECTED]
