@Scott Andrew: When copying objects, if large like imges or movies, the memory can grow quite large quite quickly
It depends on how the class of the object you're setting implements copy. Doing a copy of an immutable object (NSString, for example) will often just return the same object. I'm not sure offhand what happens with NSData and NSImage, but it wouldn't surprise me if they work this way as well. Another possibility is that you get a new object but the data it references is not copied.
My first reaction to what you wrote was that the point is moot because "copy" is not a new concept. However, after meditating on it, I see what you mean. It's much different when you can just say "copy" in the property definition and not even look at the implementation. You just start duplicating the property lines and suddenly all of your setters use copy, whether it makes sense or not.
So, yes. I do see what you mean. But I don't think it's likely to matter in the grand scheme of things.
by Scott Stevenson — Sep 27
It depends on how the class of the object you're setting implements copy. Doing a copy of an immutable object (NSString, for example) will often just return the same object. I'm not sure offhand what happens with NSData and NSImage, but it wouldn't surprise me if they work this way as well. Another possibility is that you get a new object but the data it references is not copied.
My first reaction to what you wrote was that the point is moot because "copy" is not a new concept. However, after meditating on it, I see what you mean. It's much different when you can just say "copy" in the property definition and not even look at the implementation. You just start duplicating the property lines and suddenly all of your setters use copy, whether it makes sense or not.
So, yes. I do see what you mean. But I don't think it's likely to matter in the grand scheme of things.