Menu
I understand that normally you use copy for NSStrings, so that your property stays as the same value as when you assigned it, even when there's an attempt to re-set it somewhere else.
But I am having hard time completely understanding this concept. Doesn't this apply to basically any kind of object (not just NSStrings)?
So my question is, "What kind of properties should I set as 'copy', and why?"
814
Copying an object creates a new object with the same class and properties as the original object. You copy an object when you want your own version of the data that the object contains.
The goal of the @property directive is to configure how an object can be exposed. If you intend to use a variable inside the class and do not need to expose it to outside classes, then you do not need to define a property for it. Properties are basically the accessor methods.
copy -- It creates a new object and when new object is created retain count will be 1.
assign -assign is the default and simply performs a variable assignment -assign is a property attribute that tells the compiler how to synthesize the property's setter implementation -I would use assign for C primitive properties and weak for weak references to Objective-C objects.
Objects that are simple bits of data, like strings, that won't have references to a ton of other objects in your application are great for copying.
Now you can, of course, retain things like strings instead. This will work fine. But what if you had a mutable string instead, and you modified it. Now every other object that had a reference to that string will see that modification. This may not be what you want. This is one reason copying is "simpler", because any changes to that data is localized to just that bit of code.
On the other hand, lets say you have a instance of a class you wrote for your app. It has references to other objects in your app, it has a ton of it's own strings or other values in it, and it's a complex beast. Now copying this object may not be a good idea. Chances are that if you modify this object then you want the changes to propogate to every object that holds a reference. And even if you did copy it, do you need a shallow copy (a new instance but it's ivars references the same objects) or a deep copy (a new instance containing containing new copies of every ivar)? And the object in question may not even support <NSCopying>, meaning it can't technically be copied at all.
So to sum up:
copy: Objects that are small, atomic bits of data without any internal references to other objects.retain: Nearly every other kind of object.
98
Client code can assign an NSMutableString object to an NSString property. If the property was defined as strong or some other non-copy attribute, then if the client later changes the mutable string, the property's value would now be different. By setting the property to be 'copy', a copy of the string value is made and this ensures the value can't change behind your back.
So basically you should use copy whenever the property is for a type that has a mutable counterpart and you want to ensure the value doesn't change on you.
43
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
