Does @property copy in combination with readonly make sense?

Question

If I understand this correctly, copy enforces the setter to create a copy of the object passed in. However, if I use it together with readonly , there won't be a setter. So is my assumption correct, that combining @property (copy, readonly) doesn't make any sense or am I missing something?

Answer 1

It does make sense. For instance, if you want to access a property's setter in your implementation only:

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

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

@end

and in the class continuation in the .m file:

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

Note that the copy, readonly declaration in the public header is required in this case!

Answer 2

According to Apple's documentation (which I've linked here for you):

copy
Specifies that a copy of the object should be used for assignment.

The previous value is sent a release message.

The copy is made by invoking the copy method. This attribute is valid only for object types, which must implement the NSCopying protocol.

So yes, you're correct... readonly creates a getter method and copy would be effectively ignored, since there's no setter method that does assignment.

Answer 3

你是对的，两者兼有是没有意义的。

Answer 4

I think, if I saw such a property, on read, I would expect to receive a distinct returned object to the ivar unless the returned object was advertised to be immutable.

If I have

@property (readonly, copy) NSMutableArray* foo;

and I do this:

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

I would expect myOtherFoo not to have the extra string in it that myFoo has.

Note: I haven't verified this yet.

I have checked it now and my expectation is incorrect. I think I would regard that as a bug.