individual y la diferencia de subrayado doble en declarar @synthesize

Question

En una plantilla reciente proyecto de Xcode 4.3, algunos @synthesze se declaran como:

@synthesize window = _window; 
@synthesize managedObjectContext = __managedObjectContext; 
@synthesize managedObjectModel = __managedObjectModel; 
@synthesize persistentStoreCoordinator = __persistentStoreCoordinator; 
@synthesize navigationController = _navigationController; 

Algunos vienen con un doble subrayado (__) como prefijo. ¿Por qué?

¿Algo que ver con el atributo readonly?

@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; 

Answer 1

Probablemente no se debería utilizar un doble subrayado, si están destinados a ser utilizados en su propio programa. Supongo que es solo un descuido por parte de quien escribió ese ejemplo de plantilla. En la práctica, es poco probable que causen problemas.

El estándar C reserva todos los identificadores comenzando con un doble guión bajo para uso propio de la implementación. Dado que Objective-C es un superconjunto de C, tampoco debería usar esos identificadores en los programas de Objective-C. A partir de la especificación C, sección 7.1.3 identificadores reservados:

todos los identificadores que comienzan con un guión bajo y, o bien una letra mayúscula u otra subrayado siempre están reservados para cualquier uso.

Answer 2

Probablemente en este caso. En general, apple tiende a usar _ nombres prefijados para referirse a la copia externa de una variable (como cuando se pasa como una función, o la referencia directa en oposición a la propiedad). Quien escribió ese código probablemente pensó que estaba siendo inteligente al agregar un _ adicional por solo lectura, pero esto generalmente es una mala práctica ya que C se reserva el __ para especificar las directivas del compilador.

Nunca he visto un compilador de C quejarse de __ vars, ya LLVM no parece importarle, pero probablemente no sea una buena práctica.