17
@interface PaneBean : NSObject

@property(nonatomic,copy) NSString *name;
@property(nonatomic,copy) NSString *type;
@property(nonatomic,assign) NSInteger width;
@end

I have a PaneBean as is shown above.

Whether I should use @property(nonatomic,copy) or @property(nonatomic,strong) for my (NSString *) name? What is the difference between them?

And is it right to write 'assign' for NSInteger?

Any help appreciated.Thanks in advance!

kongkong
  • 333
  • 1
  • 3
  • 12
  • 6
    Unrelated to the answer, you may want to consider learning Cocoa naming and design conventions. "Bean" is very much a Java term, and Cocoa programmers you might work with are unlikely to understand it. – Catfish_Man Aug 30 '13 at 07:13
  • oh,yes.I will edit it. – kongkong Aug 30 '13 at 07:18
  • @Catfish_Man this has got to be output from the Java to ObjC translator, "CocoaBeans" ;) – justin Aug 30 '13 at 07:36
  • 1
    possible duplicate of [Should an NSString property under ARC be strong or copy?](http://stackoverflow.com/questions/11249656/should-an-nsstring-property-under-arc-be-strong-or-copy) – TalkLittle Mar 11 '14 at 21:53

4 Answers4

15

'copy' will cause the setter for that property to create a copy of the object, and is otherwise identical to strong. You would use this to make sure that if someone sets your property to a mutable string, then mutates the string, you still have the original value. If the string isn't mutable, Cocoa will silently optimize out the copy operation, which is nice :)

'strong' will keep the property's value alive until it's set to something else. If you want incoming mutable strings to change out from under you (not impossible, but not all that common, a thing to want), then strong would be the right thing to do. Generally strong is more useful for objects that represent something more complex than a simple "value" (i.e. not NSString, NSNumber, NSValue, etc...).

'assign' is the default (and indeed only) possible setting for an integer. Integers can't be retained or copied like objects.

Catfish_Man
  • 41,261
  • 11
  • 67
  • 84
  • Since assign is the only possible setting for scaler values you should never explicitly specify it. Apple says this repeatedly in the docs. I've seen experienced coders make this mistake. – SmileBot Mar 11 '14 at 13:36
7

For attributes whose type is an immutable value class that conforms to the NSCopying protocol, you almost always should specify copy in your @property declaration. Specifying retain is something you almost never want in such a situation.In non ARC strong will work like retain

Here's why you want to do that:

NSMutableString *someName = [NSMutableString stringWithString:@"Chris"];
Person *p = [[[Person alloc] init] autorelease];
p.name = someName;
[someName setString:@"Debajit"];

The current value of the Person.name property will be different depending on whether the property is declared retain or copy — it will be @"Debajit" if the property is marked retain, but @"Chris" if the property is marked copy.

Since in almost all cases you want to prevent mutating an object's attributes behind its back, you should mark the properties representing them copy. (And if you write the setter yourself instead of using @synthesize you should remember to actually use copy instead of retain in it.)

Jitendra
  • 5,055
  • 2
  • 22
  • 42
NHS
  • 409
  • 2
  • 7
3

copy sends the copy message the object you set, while strong only retains it (increments the reference count).

For NSString , or in general any inmutable class with known mutable subclasses(NSArray, NSDictionaty, NSSet), copy is preffered to avoid clients setting a mutable instance and modifying it out of the object.

For primitive types(int for example) copy/strong does not make sense and by default assign is used. Is up to you if you want to put it explicitly or not.

e1985
  • 6,239
  • 1
  • 24
  • 39
1

Strong indicates composition, while Weak indicates aggregation.

Copy means that a new object is to be created before the contents of the old object are copied into the new object. The owning object, PaneBean in this case, will be composed of the newly created object.

Pétur Ingi Egilsson
  • 4,368
  • 5
  • 44
  • 72