Re: strong and readonly
Re: strong and readonly
- Subject: Re: strong and readonly
- From: Quincey Morris <email@hidden>
- Date: Thu, 12 Apr 2012 02:08:06 -0700
On Apr 12, 2012, at 00:58 , Thomas Davie wrote: The move from retain/assign to strong/weak/unsafe_unretained shows you why – "retain" does indeed describe an internal implementation detail – that the setter retains the object. Strong on the other hand describes extensional behaviour – that the class keeps a strong reference to the variable. This is important information – without it, it would be impossible to avoid strong reference cycles!
Take a look at section 4.1.1 of the clang ARC document:
"retain" and "strong" [as @property attributes] are just synonyms for each other, regardless of the memory model. Seeing one or other in a public .h declaration doesn't tell you anything about the implementation, not even whether ARC is being used. However, the presence of either tells you that the property promises to take ownership in the setter, which is the key fact in predicting retain cycles.
But there's some ambiguity in the usage here. "Strong reference" and "weak reference" are often used to mean "owning reference" and "non-owning reference", without necessarily implying the existence of a __strong or __weak ivar.
P.S. I *think* it's pretty trivial to come up with a -- non-synthesized, of course -- ARC setter for a @property(weak) that doesn't use a __weak ivar. (+[NSValue valueWithNonretainedObject:] sprang immediately to mind.) In such a case, it starts to become idiosyncratic whether you want to say a "weak reference" is involved.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden