Is there some purpose for this convention?
+1
A:
There are some developers who use the following convention of "hiding" there ivars by the following method:
@interface
@private
NSString *_myString
@property (nonatomic, retain) NSString *myString;
@implementation
@synthesize myString = _myString.
what this does is disallow direct access to the ivar with forcing all access via the property myString. Its a way of hiding the internals of your class and abiding by the object oriented principle of encapsulation.
ennuikiller
2010-08-23 00:49:05
Disallow is a strong word, it makes it visually obvious that you are accessing the iVar as opposed to an accessor. Nothing is stopping the user from accessing `_myString`.
Marcus S. Zarra
2010-08-23 00:51:11
@Marcus ... except the @private designation!
ennuikiller
2010-08-23 00:57:47
From the class, or from other classes? The class ought to know its internals; other classes can't access @private ivars.
tc.
2010-08-23 00:58:33
obviously from other classes!!
ennuikiller
2010-08-23 00:59:33
whoever left the downvote, but kind enough to explain why......seems rather capricious.....
ennuikiller
2010-08-23 01:01:04
The downvote was mine. You will do just as well calling the ivar _myString; the @private means it can't be accessed from other classes so there really is no point in using Apple-reserved names.
tc.
2010-08-23 01:08:29
The downvote is silly. The convention explained is a very common one. I use it all the time to make sure that there is no confusion about `myString` and `self.myString`.
St3fan
2010-08-23 02:17:17
Also, ivars with an underscore are not 'Apple Private'. Only methods with a leading underscore are.
St3fan
2010-08-23 02:18:11
@ennuikiller Even with the @private it doesn't actually stop access to the iVar. In fact, it won't even produce a warning from internal access. It is a *suggestion* for external access. Doesn't stop object->_myString from working.
Marcus S. Zarra
2010-08-23 17:08:15
@tc The down-vote is definitely inappropriate. The answer is solid and underscore on iVars **used to be** reserved by Apple but they withdrew that reservation when @property was introduced.
Marcus S. Zarra
2010-08-23 17:11:01
+1
A:
There's bit of a discussion on prefixing with underscores in:
http://stackoverflow.com/questions/566594/what-is-this-double-underscore-in-cocoa
No one in particular
2010-08-23 00:50:55
@No one in particular: shouldn't the answer be "a reason of no importance";)
Muhammad Alkarouri
2010-08-23 00:59:48
A:
Apple likes to use underscores to mean "private", according to the Coding Guidelines for Cocoa:
Avoid the use of the underscore character as a prefix meaning private, especially in methods. Apple reserves the use of this convention. Use by third parties could result in name-space collisions; they might unwittingly override an existing private method with one of their own, with disastrous consequences.
Method names beginning with underscores are reserved according to The Objective-C Programming Language (which means they're reserved even if you don't use Cocoa, presumably):
Method names beginning with “_”, a single underscore character, are reserved for use by Apple.
Additionally, the C/C++ convention is that leading underscores are (often) reserved for the implementation. A lot of people misinterpret this and use _ for anything "private"; leading to the proliferation of _FooLog() calls in a large chunk of our codebase, even though it invokes undefined behaviour.
The only reason to do it is to discourage direct ivar access in your own class. Prevent ivar access from other classes with @private.
tc.
2010-08-23 01:07:41