Menu
In a recent Xcode 4.3 project template, some @synthesze are declared as:
@synthesize window = _window;
@synthesize managedObjectContext = __managedObjectContext;
@synthesize managedObjectModel = __managedObjectModel;
@synthesize persistentStoreCoordinator = __persistentStoreCoordinator;
@synthesize navigationController = _navigationController;
Some come with a double underscore (__) as prefix. Why?
Anything to do with readonly attribute?
@property (strong, nonatomic) UIWindow *window;
@property (readonly, strong, nonatomic) NSManagedObjectContext *managedObjectContext;
@property (readonly, strong, nonatomic) NSManagedObjectModel *managedObjectModel;
@property (readonly, strong, nonatomic) NSPersistentStoreCoordinator *persistentStoreCoordinator;
@property (strong, nonatomic) UINavigationController *navigationController;
246
Enforced by the Python interpreter. Double Leading and Trailing Underscore( __var__ ): Indicates special methods defined by the Python language. Avoid this naming scheme for your own attributes. Single Underscore( _ ): Sometimes used as a name for temporary or insignificant variables (“don't care”).
Double underscores are used for fully private variables. If your class is intended to be subclassed, and you have attributes that you do not want subclasses to use, consider naming them with double leading underscores and no trailing underscores.
A single leading underscore in front of a variable, a function, or a method name means that these objects are used internally. This is more of a syntax hint to the programmer and is not enforced by the Python interpreter which means that these objects can still be accessed in one way on another from another script.
Single standalone underscore _ is a valid character for a Python identifier, so it can be used as a variable name. According to Python doc, the special identifier _ is used in the interactive interpreter to store the result of the last evaluation. It is stored in the builtin module.
Unlike single trailing underscore, there is no special meaning for double trailing underscores. You can probably think of var__ as an extension of var_. However, double leading and trailing underscore __var__ is completely different and it’s a very important pattern in Python.
Single underscore at the beginning: Python doesn't have real private methods. Instead, one underscore at the start of a method or attribute name means you shouldn't access this method, because it's not part of the API.
Single leading underscores is a convention. there is no difference from the interpreter's point of view if whether names starts with a single underscore or not. Double leading and trailing underscores are used for built-in methods, such as __init__, __bool__, etc.
The patterns we’ve discussed so far are basically different naming conventions, but with a double leading underscore, Python will behave somewhat differently. Python interpreter will do name mangling to identifiers with leading underscores.
They probably shouldn't use a double underscore, if they're intended for use in your own program. I expect it's just an oversight on the part of whoever wrote that template example. In practice, it's unlikely that they'll cause any problems.
The C standard reserves all identifiers starting with a double underscore for the implementation's own use. Since Objective-C is a superset of C, you shouldn't be using those identifiers in Objective-C programs either. From the C spec, section 7.1.3 Reserved identifiers:
All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
171
Probably in this case. In general, apple tends to use _ prefixed names to refer to the external copy of a variable (such as when passed as a function, or the direct ref as opposed to the property). Whoever wrote that code probably thought they were being clever by adding an extra _ for read-only, but this is generally bad practice since C reserves the __ for specifying compiler directives.
I've never seen a C compiler complain about __ vars, and LLVM doesn't seem to mind, but it probably isn't good practice.
22
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
