Re: NSDictionary design bug (was: Re: Ugly bug in Foundation, beware!)
Re: NSDictionary design bug (was: Re: Ugly bug in Foundation, beware!)
- Subject: Re: NSDictionary design bug (was: Re: Ugly bug in Foundation, beware!)
- From: Marco Scheurer <email@hidden>
- Date: Mon, 7 Jun 2004 14:57:48 +0200
On Jun 7, 2004, at 1:04 PM, Patrick Machielse wrote:
op 07-06-2004 01:52 schreef Marcel Weiher
I am not sure why you (and everyone else??) think you have to explain
this to
me, because the sample code was constructed to exploit/show this. I
thought
this was obvious, but obviously not obvious enough.
Pick one:
* You are vastly more intelligent than the rest of the people on the
list.
* Your post didn't convey your obvious savvyness.
I agree with Marcel that NSDictionary should not copy the keys.
No, I should not have to work around NSDictionary's buggy
implementation.
Furthermore, what I consider -isEqual: is application-dependent.
You can consider isEqual: whatever you like, as long as you obey the
implied
rule:
when b = [a copy] then [b isEqual:a] == YES must hold
I can't find a direct reference to this rule in the documentation of
NSCopying (file an enhancement request?), but I can't think of a
reason to
have a 'copy' operation return an object that is _not_ equal.
Must hold for how long? If 'a' is a mutable string then 'b' will be
immutable and a snapshot of 'a' at the time of the copy. If 'a' later
changes, [b isEqual:a] will not hold, obviously.
When you willingly violate this rule, as you do in your example, you
really
lose all hope of NSDictionary functioning.
Yes but the copying of the keys brings no advantage to the user, and
only adds burden:
(1) if the key is immutable then copying is useless (and often defaults
to retain anyway)
(2) if the key is mutable then
(2a) if its value does not change between storage and retrieval then
copying is useless
(2b) if its value change between storage and retrieval then you will
not find your object anyway.
So we have a protection that works only when it does not matter.
marco
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.