On Apr 11, 2012, at 23:58 , Thomas CLEMENT wrote: Isn't that exposing implementation details of the class that have nothing to do in its public header?
This was discussed on this list (or perhaps cocoa-dev) a week or two ago. I believe I'm summarizing the result of that discussion as follows:
The "strong" or "weak" on the @property is indeed an implementation detail in that it affects the implied declaration of a *synthesized* ivar, and the implied memory management protocol with a *synthesized* setter method. In that sense, it "really" shouldn't be on the @property but on the @synthesize instead, but that's not going to happen, in part because @synthesize is being generally de-emphasized these days.
However, the "strong" and "weak" (or "retain" and "assign", in the old days) still serve a purpose on the @property, because they inform clients of the class's API of the value object ownership behavior for the property. With "strong" or "retain", the property makes an API contract to take ownership of value objects in its setter. With "weak" or "assign", it does not take ownership. In neither case is there any API contract about the mechanism the property *actually* uses to provide that ownership behavior. (In particular, you don't know if the class uses ARC or traditional retain/release internally, in a non-GC app. And you don't know whether it @synthesized or not.)
In addition to the above, you have other cases like "copy", which affects the API contract for ownership, and affects any synthesized setter code, but has no meaning for the ivar itself.
I don't think this situation is ideal, but I have to admit that in practice there's no real problem. (Clients can't really exploit the exposed private details, I think.)
|