On Jul 10, 2008, at 11:06 AM, Jens Alfke wrote:
On 10 Jul '08, at 8:52 AM, Sean McBride wrote:
On 7/11/08 12:38 AM, Graham Cox said:
What I would suggest though is that you adopt a naming convention
for
your instance variables (ivars) that consistently flag them as such.
Some people use a leading underscore, but Apple say not to do that.
Do the docs still say that? We've had this discussion before:
<http://www.cocoabuilder.com/archive/message/cocoa/2008/4/3/203159>
With any naming convention, the possible problem is a conflict with
a name in a superclass.
Apple's Cocoa frameworks tend to use a "_" prefix for both ivars and
private method names.
Method-name conflicts are very bad and will cause trouble at
runtime. The worst case is where Apple adds a method, in a new
release of the OS, which has the same name as one of your methods.
This will probably cause your app to break because when the
framework calls that private method, it gets your implementation
instead.
Ivar-name conflicts are, IIRC, a lot less harmful. For the most
part, ivar names are used only at compile time (the generated code
just accesses ivars by a byte offset from the object) so the effect
in the above situation will be that your app continues to work fine,
but when you try to recompile the app using the SDK for the new OS,
you'll get a compile error about a duplicate ivar name. Then you
just rename yours.
Someone did bring up the issue of dynamic ivar-name lookups. KVC
sometimes uses these. It's possible there could be runtime problems
in this case, although I'm not sure. All I can say is that I've been
using the "_" prefix in my code for almost eight years now without
running into such problems.
The problem is that while when you recompile you'll see the conflict,
for existing users (who won't be compiling from source), if they use
KVC they'll have the problem.
@interface NSFoo {
id _reserved;
}
@end
@interface MyFoo: NSFoo {
float _value;
}
@end
And OS X+1 comes out with:
@interface NSFoo {
int _value;
}
@end
Any of your code that used _value (like, say, for bindings) could
suddenly break for users of OS X N+ 1 (since they won't be compiling
from source to see what is going on).
Granted, it's rare that this happens, but from time to time reserved
fields do get converted to something used. And lets face it, if you
hear "it works fine on OS X N, but breaks on OS X N+1", "ivar
collision" isn't the first thing you'll think about to try to track
down the problem...
Worse, this could actually happen on an OS X N+ 0.1 release and the
headers wouldn't get updated so you won't even have the safety net of
seeing compiler errors. Similarly, if you target the OS X N SDK, you
won't see the new headers either.
"Haven't run into such problems" != "Such problems don't happen"
Glenn Andreas [EMAIL PROTECTED]
<http://www.gandreas.com/> wicked fun!
JSKit | the easy way to unite JavaScript and Objective C
_______________________________________________
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]
