NSString @property, using copy instead of retain

Question

I'm looking over Apple's sample application EditableDetailView, and noticed that in one of their controllers, they're setting an instance of NSString property with (nonatomic, copy). When would one use copy instead of retain? Is this so they can make a unique copy without affecting the existing data?

Answer 1

Yes, it's so that it can make a unique copy without affecting the existing data. The synthesized setters essentially look like this:

// For @synthesize(nonatomic, retain) foo:
- (void) setFoo(NSFoo *theFoo)
{
    [theFoo retain];  // retain new value
    [foo release];    // release old value, if any
    foo = theFoo;     // assign new value
}

// For @synthesize(nonatomic, copy) foo:
- (void) setFoo(NSFoo *theFoo)
{
    NSFoo* newFoo = [theFoo copy];  // make copy
    [foo release];  // release old value, if any
    foo = newFoo;   // assign new value
}

Note the order of operations here is important - the new value must be retained/copied before the old value is released, in case of self-assignment. If you released first and then assigned the property to itself, you might deallocate the value by accident. Also note that if the old value is nil, sending it a release message is ok, since sending a message to a nil object is explicitly allowed and does nothing.

The choice of retaining versus copying just determines whether or not the object's property shares the same value with what you're setting it to. Consider the following code:

// suppose the 'foo' property is declared 'retain' and the 'bar' property is
// declared 'copy'
NSFoo *foo = ...;
NSBar *bar = ...;
someObject.foo = foo;
someObject.bar = bar;
[foo changeInternalState];  // someObject.foo also changes, since it's the same object
[bar changeInternalState];  // someObject.bar does NOT change, since it's a copy

Answer 2

Remember that there is an NSMutableString. It would be really bad to be able to mutate the contents of a string that some other object owns (say, by deleting half its characters), especially if you don't realize you're affecting another object. Therefore, it's nice for the other object to make its own copy.

You may say “well, why don't I just copy the string before assigning it there?”. Maybe the object wants a mutable string and yours is immutable. If you have to copy the string first, then you have to look up which kind of string it wants in its documentation or header, then make the right kind of copy (every time). This way, you just say other.string = myString and it makes whatever kind of copy it wants—you don't have to worry about it.