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: Patrick Machielse <email@hidden>
- Date: Mon, 07 Jun 2004 23:43:43 +0200
op 07-06-2004 14:20 schreef Alastair Houghton
>
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.
[]
>
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.
The code above will work for a well designed key class. It is the user that
broke the implicit 'copy is equal' contract for MyObject.
>
> 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
>
>
>
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.
I don't propose this rule. You can deduce it from the documentation of
NSDictionary.
>
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.
This may be true, but if you design objects like this you just can't use
them as dictionary keys. This may be a disadvantage to some. However, in any
of these cases it is probably easy to change the objects' designs such that
they _can_ be used as keys.
>
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.
I think it only places a constraint on -isEqual: namely that 'copy' creates
two equal objects. This is indeed an extra consideration when designing an
object that will be used as a dictionary key. I don't see how this impaires
the usefulness of NSDictionary though.
Patrick
---
Hieper Software
w: www.hieper.nl
e: email@hidden
_______________________________________________
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.