Re: ObjC 2.0, properties, KVC, special _ hacks etc.
Re: ObjC 2.0, properties, KVC, special _ hacks etc.
- Subject: Re: ObjC 2.0, properties, KVC, special _ hacks etc.
- From: Negm-Awad Amin <email@hidden>
- Date: Sun, 24 Aug 2008 15:32:34 +0200
Am Fr,22.08.2008 um 04:59 schrieb Thomas Engelmeier:
Am 22.08.2008 um 00:59 schrieb Dave MacLachlan:
Also, are the _ in front of member variables for Apple only (so we
don't stomp on each other with member var names) or are they using
them for the readability reason mentioned above? There is
documentation where they have claimed _ at the beginning of method
names as being Apple only, but nothing about method vars, and the
KVC compliance docs seem to imply that it is fine to do.
Officially it is Apple only, but everybody and his dog uses it - in
consistency to quite some Apple-provided samples.
Also, in C++ the _ variable prefix is reserved for stdlib-
implementation.
The reasoning why many people do not consider it as problematic if
there is a collision with an Apple defined _ prefixed ivar is you
will see an compiler error once there is a collision.
For methods OTOH, you don't get an warning but potential runtime
crashes and undefined behavior.
Some people uses the leading underscore for a convention, that
something is private:
@interface FrameworkClass:… {
NSNumber* _myPrivateNumber;
}
---
@implementation …
- (void)_myPrivateMethod
Apple says, that underscored names are for apple use only. On the
first sight it looks like, that this system helps avoiding collisions:
Framework classes with, custom classs without underscore.
But that's not true. If you use standard accessor naming, the
collision will be moved from ivars to accessors. Example:
- (void)setMyPrivateNumber:… // I'venever seen set_myPrivateNumber:
When you subclass a framework class and "accidentially" add your own
ivar "myPrivateNumber", you usually will have a setter:
- (void)setMyPrivateNumber:…
The compiler wouldn't warn, because the ivars have different names.
The "new" setter to the new ivar looks like overwriting to the
compiler and he wouldn't warn again. So you have a collision without
any warning of nobody. The "underscore solution" makes it worse, not
better …
In former times this was the reason to me, to break with the apple
convention and use the underscore, too. In this case the compiler will
warn me because of the double ivar. (There is no ivar overwrtiting in
Objective-C.) However I stopped doing so, because it is against the
rule, unusual for most readers and the risk of a conflict is not that
high, if you choose your ivars with some care about this problem. So
do not use names like "count" and so on, but
"countOfPersonsStored" (just an example) and so on.
But IMHO, it would be a good idea, that apples stops with the
underscore rule, too.
Cheers,
Amin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
Amin Negm-Awad
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden