Re: design question
Re: design question
- Subject: Re: design question
- From: Ariel Feinerman <email@hidden>
- Date: Wed, 23 Mar 2011 13:04:48 +0200
thank you very much for your answers.
2011/3/23 Graham Cox <email@hidden>
>
> 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
>
>
>
--
best regards
Ariel
_______________________________________________
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