Si entiendo esto correctamente, copy obliga al colocador a crear una copia del objeto pasado. Sin embargo, si lo uso junto con readonly, no habrá un colocador. Entonces, ¿mi suposición es correcta, que combinar @property (copy, readonly) no tiene ningún sentido o me falta algo?¿@property copy en combinación con readonly tiene sentido?
Tiene sentido. Por ejemplo, si desea acceder a seleccionador de propiedades sólo en su aplicación:
@interface MyClass : NSObject
@property (nonatomic, copy, readonly) NSData *data;
- (id)initWithData:(NSData *)data;
@end
y en la continuación de clase en el archivo .m:
@interface MyClass()
@property (nonatomic, copy, readwrite) NSData *data;
@end
Tenga en cuenta que la declaración copy, readonly en la cabecera pública es requerido en este caso!
Se aplican las mismas consideraciones si una subclase desea redeclarar una propiedad 'readonly' definida en la superclase como' readwrite' en su propia implementación. – Monolo
Este es un caso especial bastante raro en mi experiencia, sin embargo, tiene toda la razón (ambos), en este caso tan especial, uno necesita 'copy' incluso para una propiedad de solo lectura. – Mecki
Tiene razón, no tiene sentido tener ambas.
Según Apple's documentation (que yo he vinculado a su disposición):
copy
Especifica que una copia del objeto se debe utilizar para la asignación.El valor anterior se envía un mensaje
release.La copia se realiza invocando el método
copy. Este atributo es válido solo para tipos de objetos, que deben implementar el protocoloNSCopying.
Así que sí, tiene usted razón ... readonly crea un método getter y copy se ignoraría de manera efectiva, ya que no hay método de selección que hace la asignación.
Esta debería ser la respuesta aceptada ... ya que en realidad _ responde_ la pregunta, lol. –
Creo que, si vi una propiedad así, al leer, esperaría recibir un objeto distinto devuelto al ivar a menos que el objeto devuelto se anunciara como inmutable.
Si tengo
@property (readonly, copy) NSMutableArray* foo;
y hago esto:
NSMutableArray* myFoo = [theObject foo];
[myFoo addObject: @"string"];
NSMutableArray* myOtherFoo = [theObject foo];
yo esperaría myOtherFoo de no tener la cadena extra en lo que tiene myFoo.
Nota: No he verificado esto todavía.
Lo he comprobado ahora y mi expectativa es incorrecta. Creo que lo consideraría un error.
La anotación "copiar" significa copiar-en-conjunto, no copiar-en-conseguir. –
@HotLicks, err, sí, lo sé. ¿No leíste las dos últimas líneas de mi respuesta? Personalmente, todavía lo considero un error. – JeremyP
¿Por qué esperas modificar el objeto y no tener el cambio visible? Dos accesos de la propiedad "foo" buscarán referencias al mismo objeto. –
Una buena pregunta, me pregunto si la etiqueta 'readonly' solo hace que el setter sea un método privado, por lo que aún realizaría una copia cuando lo configurara dentro de la clase misma. es decir 'self.myProperty = newThing;' –
El doc de Apple tiene esto: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/ uid/TP30001163-CH17-SW19 – kennytm