{"id":281,"date":"2009-03-17T01:25:29","date_gmt":"2009-03-17T06:25:29","guid":{"rendered":"http:\/\/vgable.com\/blog\/2009\/03\/17\/mutable-property-and-copy-gotcha\/"},"modified":"2009-03-17T01:53:42","modified_gmt":"2009-03-17T06:53:42","slug":"mutable-property-and-copy-gotcha","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2009\/03\/17\/mutable-property-and-copy-gotcha\/","title":{"rendered":"Mutable @property and Copy Gotcha"},"content":{"rendered":"

If you have a @property<\/a><\/code> for an object who’s name starts with NSMutable<\/code>, and you use the copy<\/code> declaration attribute, then the code that is synthesized for you is not correct.<\/strong> Because it uses copy<\/code>, not mutableCopy<\/code>, to do the copy during assignment, the value will not<\/em> be mutable.<\/p>\n

Here’s a demonstration,<\/p>\n

\n@interface Gotcha : NSObject {\n\tNSMutableString *mutableString;\n}\n@property (copy) NSMutableString *mutableString;\n@end\n@implementation Gotcha\n@synthesize mutableString;\n@end\n
...\nGotcha *x = [[[Gotcha alloc] init] autorelease];\nx.mutableString = [NSMutableString stringWithString:@\"I am mutable.\"];\n[x.mutableString appendString:@\" Look at me change.\"]; \n<\/pre>\n
It crashes with the message,<\/p>\n
*** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘Attempt to mutate immutable object with appendString:’<\/p><\/blockquote>\n
copy<\/code> vs mutableCopy<\/code><\/h3>\n
The copy<\/code><\/a> method returns an immutable<\/em> copy of an object, even if the object is mutable. Eg the copy<\/code> of an NSMutableString<\/code> is an immutable NSString<\/code>.<\/p>\n
The mutableCopy<\/code><\/a> method returns a mutable copy of an object, even if the object is not mutable.  Eg., the mutableCopy<\/code> of an NSString<\/code> is an NSMutableString<\/code> object.<\/p>\n
@synthesize<\/code> always uses copy<\/code> in the setters it generates. That means an immutable<\/em> copy will always be stored, even if an NSMutable<\/code> object is given.<\/p>\n
Workarounds<\/h3>\n
Apple says<\/a>, ” …In this situation, you have to provide your own implementation of the setter method<\/strong>..”  (To me, this isn’t as satisfying of an answer as a mutablecopy<\/code> attribute.  But it’s what Apple has chosen, so all we can do is file enhancement requests<\/a> and trust their reasoning).<\/p>\n
Another workaround is to make any property that is a mutable value readonly<\/code><\/strong>.  If something is mutable, you can change it’s contents directly, so there is rarely a need to set it.  For example, with the Gotcha<\/code> object, it’s just as easy to say<\/p>\n
[x.mutableString setString:@\"New String\"];<\/pre>\n
as<\/p>\n
x.mutableString = [NSMutableString stringWithString:@\"New String\"];<\/pre>\n
Finally, you might consider using an immutable readwrite<\/code> property<\/strong>. In my experience, immutable objects are generally safer, and often faster (I owe you an article on this, but there are plenty of articles on the benefits of immutability<\/a>).  I know this sounds like a smart-ass suggestion, and it won’t be a good answer much of the time<\/em>.  But it’s surprising how often things turn out not to need mutability once a design matures.  Since reducing the mutability of an object often improves it, and it does work around the problem, it’s worth at least considering this solution.<\/p>\n
Why not Just Use retain<\/code>?<\/h3>\n
Changing the copy<\/code> to retain<\/code> well let you assign a mutable object, but I do not like the idea.  My article, Prefer copy<\/code> Over retain<\/code><\/cite><\/a> explains in detail.  My biggest worry is aliasing,<\/p>\n
\nNSMutableString *aLocalString = [NSMutableString string];\nx.mutableString = aLocalString;\n[x doSomething];\n\/\/aLocalString might have been changed by doSomething!\n\/\/\n\/\/ 300 lines later...\n\/\/\n[aLocalString appendString:@\" now with more bugs!\"];\n\/\/x has been changed too!\n<\/pre>\n
Using retain<\/code> with NSMutable<\/code> objects is asking for bugs.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
If you have a @property for an object who’s name starts with NSMutable, and you use the copy declaration attribute, then the code that is synthesized for you is not correct. Because it uses copy, not mutableCopy, to do the copy during assignment, the value will not be mutable. Here’s a demonstration, @interface Gotcha : […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18,6,5,4],"tags":[371,372,373,263],"class_list":["post-281","post","type-post","status-publish","format-standard","hentry","category-bug-bite","category-cocoa","category-objective-c","category-programming","tag-property","tag-synthesize","tag-nsmutable","tag-objective-c-20"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/281","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=281"}],"version-history":[{"count":0,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/281\/revisions"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=281"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=281"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=281"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}