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: Alastair Houghton <email@hidden>
- Date: Mon, 7 Jun 2004 13:20:33 +0100
On 7 Jun 2004, at 12:04, 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.
Actually, *I* agree with what Marcel is saying, although I've been
keeping quiet (mainly because I'm painting my garage floor at the
moment, so I'm a bit busy to get thoroughly involved). The fundamental
point is that it doesn't make any sense whatsoever for
MyObject *obj = [[MyObject alloc] init];
NSMutableDictionary *dict = [[NSDictionary alloc] init];
[dict setObject:@"Hello" forKey:obj];
NSLog (@"%@", [dict objectForKey:obj]);
to do anything other than display "Hello" on the console. Regardless
of the issue of whether or not bugs attributable to mutable keys in
dictionaries would be common or not in practice (and I agree with
Marcel here that they probably aren't common at all), that snippet of
code should work. MyObject fulfils all of the requirements stated for
-isEqual: and -hash, and it is the *NSDictionary* that is storing a
different key to the one that it was given, *not* the user.
>
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.
If the only thing about the object is its existence---i.e., if it
doesn't actually have any instance data---then it makes a great deal of
sense for a -copy'd object to break the rule you propose. There are
uses for these types of object; for instance, they could be used to
provide a unique identifier without requiring additional unnecessary
storage, or they might be used as some sort of NULL value, perhaps to
mark the boundaries of a data structure or to provide a particular set
of semantics in an expression that has been built into a parse tree of
objects.
>
When you willingly violate this rule, as you do in your example, you
>
really
>
lose all hope of NSDictionary functioning.
But only because NSDictionary places additional constraints on
-isEqual: and -hash that Marcel and I contend are unnecessary and
prevent some otherwise legitimate uses of the NSDictionary class.
The fact that the documentation also implies that NSDictionary works
how *we* think it should would seem to indicate that it was originally
designed to work that way and later "fixed", probably when someone
didn't heed the warning about mutable keys in dictionaries.
Kind regards,
Alastair.
--
http://www.alastairs-place.net
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.