On 23/03/2011, at 11:58 AM, Quincey Morris wrote: > 1b. The property is a to-many relationship. > > If #1a, then the return value should be unchangeable, in the sense that it > should never change after being returned (regardless of whether the returned > object is of a mutable class or not). That means, if an existing mutable > array is the desired return value, which the owning class might mutate later, > a copy *must* be returned instead. > > If #1b, then the return value should be assumed to be changeable, in the > sense that it could change any time after being returned. (Again, the return > value's class's mutability is irrelevant.) *Semantically, what's being > returned is a "proxy" for the relationship*, not an array. In this case, the > return type merely indicates whether the caller can mutate the relationship > via the "proxy" or not. > > In practice, it works in reverse. If the method returns something > unchangeable, the property is regarded as an attribute. If it returns > something changeable, the property is regarded as a to-many relationship. > > This is consistent with Core Data properties, and keeping the distinction > clear keeps the API design honest and helps write correct code -- it makes it > easy to decide whether to return a copy of the underlying array or not. > > Your discussion about "how long" and "why" has different answers depending on > which of the two kinds of properties is involved. The pitfall here is that if > the property is intended to be a snapshot of the state of a relationship (an > attribute, as opposed to the actual relationship), returning the underlying > mutable array without copying is a bug, even if the return type is NSArray.
Right, and I agree. You've expressed it better than I did, sometimes it's hard to convey in writing something that you have only understood at some intuitive level. So this helps clarify something I hadn't made entirely clear in my own mind. The situation is #1b. And you know this, because you have more information than just a return type - you have the name of the method, -children. This pretty much tells you that you're dealing with a to-many relationship. If it doesn't, you've named it badly. Thus, a client can and should expect it to change, and so, if it actually wants a snapshot, it should perform the copy, but if not, it shouldn't cache it. Either way, in my view the onus is on the client as to whether to perform the copy - the vending object doesn't know what the client is going to use it for, so whether to copy it or not is not something it can know, so it should do the simplest thing (an instance of Occam's Razor?) which is, not copy. In practice, you rarely run into problems with this approach. I know everyone will have their favourite counter-examples, but that's why I say 'rarely', not 'never'. --Graham _______________________________________________ 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
