¿Cuál es el propósito de un ivar cuando existe una propiedad?

Question

Lo siguiente no se queja en la compilación ni en el tiempo de ejecución sobre no name ivar. Entonces, ¿por qué es tan común ver un ivar y@property/@synthesize.

@interface PropTest : NSObject 
{ 
} 
@property (retain) NSString *name; 
@end 

@implementation PropTest 
@synthesize name; 
@end 

int main (int argc, const char * argv[]) { 
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; 
    PropTest *p = [[PropTest new] autorelease]; 
    p.name = @"Hello, World!"; 
    NSLog(@"%@",p.name); 
    [pool drain]; 
    return 0; 
} 

impresiones de este código

Hello, World! 

De hecho, si tengo acceso p->name, recibo una advertencia:

warning: instance variable 'name' is @private; this will be a hard error in the future 

lo que indica que se crea una Ivar para mí si uno doesn' t existe.

Si eso es cierto, ¿de qué sirve crear el ivar manualmente (ignorando lo obvio, que a veces hay razones válidas para no usar el accesorio g/setter)?

O preguntó de manera diferente, debo solamente siemprecrear una Ivar una propiedad cuando necesito pasar por alto los descriptores de acceso?

Answer 1

Los ivars sintetizados (la capacidad de no declarar ivars de forma manual) son una característica del nuevo tiempo de ejecución de Objective-C, que aún no se usa en todos los sistemas. Para Mac de 32 bits (y, hasta hace poco, el simulador de iPhone), debe declarar ivars manualmente. Si solo está segmentando sistemas con el nuevo tiempo de ejecución, no hay ninguna razón para declarar ivars manualmente.

Answer 2

La respuesta de eman es correcta en general, pero hay una razón para declarar aún ivars incluso en el nuevo tiempo de ejecución: Apple desalienta los accesos sintetizados en los métodos init y dealloc. Esencialmente, los getters y setters pueden tener efectos secundarios además de solo establecer una variable. En particular, podrían desencadenar notificaciones KVO. Con un ivar para hablar, solo puede enviar release y terminarlo. Pero si todo lo que tienes es una propiedad, tu única opción es configurarlo y esperar que evites cualquier interacción desafortunada.

No estoy seguro de cuán grande es este problema en la práctica, para ser honesto. Simplemente lo he evitado supersticiosamente, aunque secretamente dudo que cause un problema en la mayoría de los casos. Pero Apple hace un punto de esto en los documentos, así que supongo que hay alguna razón para preocuparse.

razones

Answer 3

dos no tan buena, pero-necesarias para que las propiedades estén respaldadas por Ivars:

1. Por alguna razón el depurador XCode no muestra propiedades que no tienen Ivars correspondientes de forma explícita declarado.
2. Me parece que en ciertas circunstancias utilizando @property sin una Ivar puede ocultar otros Ivars, lo que resulta en errores de compilación (ver Why does a subclass @property with no corresponding ivar hide superclass ivars?)

A menos tengo los extremos incorrectos de un par de palos aquí , Creo que el uso de @property sin ivars explícitos puede conducir a molestias no justificadas por la conveniencia.