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.
And of course, if the client wants a mutable dictionary, there is
nothing wrong with calling -mutableCopy on the returned secretly
mutable dictionary.
If you are just saying that you shouldn't explicitly write in the
documentation "returns an immutable dictionary" if you actually return
a mutable dictionary, then sure, that makes sense.
But using NSDictionary as a placeholder for something that actually
happens to be mutable seems fine to me if you don't want to have
clients relying on the method's implementation using a mutable
dictionary internally.
I'm pretty sure I have seen the Cocoa frameworks doing this.
Or are there other concerns, like breaking the technique here of
checking for the classForCoder? Like people have been saying, that
seems like bad design to me anyway.
Adam Leonard
_______________________________________________
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 [EMAIL PROTECTED]
