Re: Use of assign vs. copy for accessors in Garbage Collected app
Re: Use of assign vs. copy for accessors in Garbage Collected app
- Subject: Re: Use of assign vs. copy for accessors in Garbage Collected app
- From: Rick Hoge <email@hidden>
- Date: Wed, 28 Nov 2007 08:29:21 -0500
Thanks for this and other replies (see comments below)
I'm experimenting with use of the @property declaration in a new
app. Quite a few of my classes would be substantially simplified
if this works as advertised. I'm also evaluating whether this new
application would be a good candidate for Garbage Collection.
In reading the docs, a question came up regarding whether to use
@property(copy) or @property(assign). In particular the following
text is relevant:
assign
Specifies that simple assignment should be used in the setter.
This is the default.
If you use this keyword and your application does not use garbage
collection (GC), you get a compiler warning as this is rarely the
correct behavior. For non-GC applications, you must explicitly
specify one of the storage behavior attributes to avoid a warning
for objects.
For applications that use GC, you will get a warning for this
attribute if the variable adopts the NSCopying protocol as assign
would typically be incorrect in that situation.
Can someone spell out for me why assign is bad in a GC app, and
copy is good?
Assign isn't "bad" nor is copy "good" they just do different things
and...
I would expect this would depend on the nature of the relationship
between the objects being represented.
Exactly, you answered your question :)
Ok - this is what I'd hoped. As mentioned by another poster, the docs
are a little ambiguous. Will file a bug.
I need to know whether there may be any hidden problems in using
@property(assign) in a GC app in cases where I don't want to copy
the object which is input as an instance variable.
No hidden problems as long as potential mutation of the object
(assuming it is mutable) isn't an issue... OK I believe one "hidden"
issues exists when an assigned mutable object is mutated KVO will
not trigger for that property.
Sometimes it's just necessary to refer to another object that may
change. Typically I register key-value observers for the properties
of the other object I'm interested in (e.g. [otherObject
addObserver:self forKeyPath:@"someIvar" options:0 context:nil];) and
handle change notifications in
-(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object
change:(NSDictionary *)change context:(void *)context {
// Handle the change here
}
This is tedious, but seems to work. Of course I usually put the
addObserver method in the setter, so automatic setter generation
through @synthesize is of no use anyway. However I could replace the
verbose set/get declarations in the .h file with a more concise
@property declaration I suppose.
Thanks again - still trying to get my head around how these will
actually be used in real-world apps.
Rick
-Shawn
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden