On Nov 13, 2011, at 2:48 AM, ico wrote: > We always use copy attribute on the NSString property declaration because > it will figure it out that when you pass a mutable copy, if will copy then > make the object to be immutable version and assign it to your property, and > it will retain if you pass an immutable version. > That's very cool and is the most often situation we want. > > However, I really hard to see people use the same technique on NSArray and > NSDictionary. > If the reason for NSString holds true, why not we also use copy on NSArray > and NSDictionary property declaration? > I see most of time, developer just use retain attribute on them. > > why?
The decision whether to use copy or retain should be semantic. The fact that immutable objects can optimize copying by just retaining themselves is an optimization and an implementation detail. It should not factor into the decision of whether the property should copy or retain, at all. Depending on the nature of the property, it is often most appropriate to use the "copy" attribute for an NSArray or NSDictionary. I can't comment as to why you more often see code using "retain". What you have to consider is whether the property is an attribute property or a relationship property. For example, a Department class may have a "name" property. That's an attribute of the department. The name is an intrinsic part of the department. It makes sense for the department to copy that because it shouldn't be shared with other objects. The department doesn't "have a relationship" with a free-floating string object which plays the role of its name, it simply has a name. On the other hand, the Department class may have a "manager" property of class Employee. This is a to-one relationship. The employee has an existence independent of the department. Also, it doesn't typically make sense for an Employee to be copied. Now, an array property is most often used to implement a to-many relationship. So, a Department may have an "employees" property implemented using an array. The Department owns the array but is merely related to each Employee in the array. In that case, the "employees" property should be a "copy" property. But it's at least conceivable to have a to-one relationship to an array. In that case, such a property would use the "retain" attribute. It does seem improbable, though. A contrived example may be that a Department is related to a mutable array representing a pool of available meeting rooms. Multiple departments may all use the same pool. They reserve a meeting room by removing the room from the pool and they relinquish a room by adding it back into the pool. The same sort of logic applies to dictionary properties. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
