I have four variations of the same class.
A mix of pointer, non-pointer, assign vs copy.
What are the implications of using each case?
1)
@interface fruit:NSObject{ NSString apple; } @property(nonatomic, retain); @end
2)
@interface fruit:NSObject{ NSString apple; } @property(nonatomic, assign); @end
3)
@interface fruit:NSObject{ NSString *apple; } @property(nonatomic, retain); @end
4)
@interface fruit:NSObject{ NSString *apple; } @property(nonatomic, assign); @end
Best Answer
1)
You cannot allocate
NSObjects
on the stack or as object instance variables. In its early days, Objective-C did allow this, but it doesn't anymore. This code is incorrect.2)
You cannot allocate
NSObjects
on the stack or as object instance variables. In its early days, Objective-C did allow this, but it doesn't anymore. This code is incorrect.3)
You are retaining an ownership stake in the
NSString
instance, guaranteeing that it will not be deallocate while you retain that ownership. SinceNSMutableString
is a subclass ofNSString
, you may have been given a mutable string at assignment, so other code may modify the string's value without your knowledge (unless you are using Key-Value Observing to observe those changes). For this reason, it is usually appropriate to usecopy
semantics for properties that you intend to hold an immutable value (NSString
,NSData
,NSArray
,NSSet
are the common--though not exaustive--suspects).4)
You are not retaining an ownership interest in the string, meaning that it may be deallocated without your knowlege. In reference-counting environments, this is the standard practice for delegate properties, since retaining them would likely create a retain cycle. The code that is responsible for deallocating the string must set your apple property to nil before doing so (in a ref-counted environment). In a GC environment, your assignment will keep the string alive if you have a __strong pointer or give you a zeroing (set to 0 at dealloc) if you have a __weak pointer in your declaration.