On Apr 7, 2008, at 9:39 AM, Jens Alfke wrote:
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.)
Right, but by having dummy placeholders, they can later rename
"_extra" to "_something", and if you have an ivar named "_something"
there will be problems. (For that matter, they could also change
existing ivar names as well).
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.
In the case of renaming _extra to _something, no.
For example, an OS update comes out where a framework has a change
like this. Customer upgrades the OS. There is KVC based access to
[obj setValue: newValue forKey: @"_something"] (either in your code,
or in the updated framework - perhaps in NIB loading). Suddenly there
is a collision - KVC will change one of them, even though the hard-
coded access methods will still be grabbing their own respective
versions.
So while this isn't exactly the same FBC problem (ivar offsets change
in already-compiled code) it is very much like it (ivar named access
changes to a different offset in already compiled code).
Worse, you won't be able to get the compiler to tell you about this
error until you get new headers with that change. But if you are
compiling against an SDK (which you probably are), you won't see that
change (since you'll just get the earlier headers). All you're left
with is trying to track down why, for example, an outlet is nil after
loading a NIB that works fine under the last OS version but fails
under this one (and/or stranger problem than that).
And, of course, with ObjC 2.0, new ivars can be added, again that can
conflict with your usage of leading underscores, increasing the chance
that you'll see this sort of problem.
Avoiding this sort of hard to track down problems seems well worth the
price of using something other than a leading underscore on your
ivars...
Glenn Andreas [EMAIL PROTECTED]
<http://www.gandreas.com/> wicked fun!
quadrium | flame : flame fractals & strange attractors : build,
mutate, evolve, animate
_______________________________________________
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]
