La copia di @property in combinazione con readonly ha senso?

Question

Se ho capito bene, copy impone al setter di creare una copia dell'oggetto passato. Tuttavia, se lo uso insieme a readonly, non ci sarà un setter. Quindi la mia ipotesi è corretta, che la combinazione di @property (copy, readonly) non ha alcun senso o mi manca qualcosa?

Answer 1

Ha senso. Ad esempio, se si desidera accedere setter di una proprietà nella implementazione solo:

@interface MyClass : NSObject 
@property (nonatomic, copy, readonly) NSData *data; 

- (id)initWithData:(NSData *)data; 

@end 

e nella continuazione classe nel file .m:

@interface MyClass() 
@property (nonatomic, copy, readwrite) NSData *data; 
@end 

Nota che la dichiarazione copy, readonly nell'intestazione pubblico è richiesto in questo caso!

Answer 2

Hai ragione, non ha senso avere entrambi.

Answer 3

Secondo Apple's documentation (che ho linkato qui per voi):

copy
Specifica che una copia dell'oggetto deve essere utilizzata per l'assegnazione.

Il valore precedente viene inviato un messaggio release.

La copia viene effettuata mediante il richiamo del metodo copy. Questo attributo è valido solo per i tipi di oggetto, che devono implementare il protocollo NSCopying.

Quindi sì, siete sulla strada giusta ... readonly crea un metodo getter e copy sarebbe effettivamente ignorato, dal momento che non c'è nessun metodo setter che fa assegnazione.

Answer 4

Penso che, se avessi visto una tale proprietà, in lettura, mi sarei aspettato di ricevere un oggetto restituito distinto per l'ivar a meno che l'oggetto restituito fosse pubblicizzato come immutabile.

Se ho

@property (readonly, copy) NSMutableArray* foo; 

e faccio questo:

NSMutableArray* myFoo = [theObject foo]; 
[myFoo addObject: @"string"]; 
NSMutableArray* myOtherFoo = [theObject foo]; 

mi aspetterei myOtherFoo non avere la corda in più in esso che ha myFoo.

Nota: non ho ancora verificato questo.

L'ho controllato ora e la mia aspettativa non è corretta. Penso che lo considererei un bug.