----- Original Message ----
> From: Adam Leonard <[EMAIL PROTECTED]>
> To: I. Savant <[EMAIL PROTECTED]>; [email protected]
> Sent: Monday, December 8, 2008 2:15:47 PM
> Subject: Re: NSDictionary mutability test
>
> >
> > The only thing you could consider "broken" is if the method promises
> > an immutable object but gives you a mutable one (or vice-versa).
>
> I agree that it is definitely wrong to declare method as returning a mutable
> object, and actually returning a immutable object instead.
>
> But is it really true that it is wrong to do it the other way around?
>
> I often declare a method as returning an NSDictionary, but in the actual
> implementation, I work with an NSMutableDictionary. It seems sort of
> pointless
> to do a "return [[mutableDictionary copy]autorelease]" on it, since a mutable
> dictionary can do everything a immutable dictionary can. Either way, the
> receiver should not be trying to call any mutating methods on something that
> is
> declared to return an NSDictionary *, so there should be no adverse effects.
Yes, that makes sense. It's the Liskov substitution principle. You can
substitute a subclass in place of its superclass, but not vice versa. If the
interface says it's an NSDictionary, it should be treated like an NSDictionary,
but there's no need that it actually be immutable as long as you can treat it
that way.
Cheers,
Chuck
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [EMAIL PROTECTED]
