On Sat, Jan 10, 2009 at 12:08 PM, Alastair Houghton <alast...@alastairs-place.net> wrote: > On 10 Jan 2009, at 16:48, Michael Ash wrote: > >> As for underscore being reserved, I have never been able to figure out >> any consequence of a conflict with an Apple ivar name. It may cause >> your source to fail to compile, but it won't cause any *binary* >> compatibility problems, which is the real menace. > > I *think* the problem here is introspection... if you subclass an Apple > provided class and add an instance variable with the same name as one of > theirs, it's possible that any of the dynamic mechanisms the frameworks (or, > for that matter, your own code) use to get the value of an object property > might use the wrong variable, with unexpected results.
Not using an underscore won't save you here. Mechanisms like KVC will look for ivars both with and without the underscore. In fact, leaving off the underscore makes things worse: with the underscore, the compiler will at least error when you try to recompile later on, whereas without it the conflict will exist silently. A cow-orker just pointed out to me that Apple does not, in fact, recommend against an underscore prefix for instance variables. They do recommend against them for private methods, but that's a completely different question. It seems that the well-known recommendation against _ivars is actually a misconception! If I'm wrong and just missed it, I'd like to know where it says so. But no trace of such a recommendation in Coding Guidelines for Cocoa: Naming Instance Variables and Data Types: http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284 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
