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: Shawn Erickson <email@hidden>
- Date: Mon, 7 Jun 2004 08:00:57 -0700
On Jun 7, 2004, at 7:20 AM, Marco Scheurer wrote:
On Jun 7, 2004, at 1:04 PM, Patrick Machielse wrote:
The design bug is in your MyObject class, which creates copies which
are not
'equal', not in NSDictionary.
And please let me also point out that NSSet is implemented differentl,
i.e. unlike NSDictionary, which at least hows some inconsistency. IMHO
NSSet's implementation is "correct".
NSSet does not copy the objects: "Objects added to a set are not
copied; rather, an object receives a retain message before its added
to a set."
Like NSDictionary, NSSet depends on the hash and isEqual: methods:
"Objects in a set must respond to the NSObject protocol methods hash
and isEqual:. See the NSObject protocol for more information."
However, the documentation goes as far as saying this about storing
mutable objects: "Note that if mutable objects are stored in a set,
either the hash method of the objects shouldnt depend on the internal
state of the mutable objects or the mutable objects shouldnt be
modified while theyre in the set (note that it can be difficult to
know whether or not a given object is in a collection)."
This totally contradicts all the arguments put forward so far in favor
of copying the keys in NSDictionary! You could argue that "the hash
method of the objects shouldnt depend on the internal state" is wrong
but does anybody want to come out in favor of copying objects in
NSSets? If not, why should keys be copied in NSDictionary?
All quotes are from :
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
ObjC_classic/Classes/NSSet.html
It doesn't contradict any thing...
NSDictionary depends on the keys used to have hash and isEqual that
depend on the contents of the object, its meaning if you like, not a
particular instance of the class. If immutable you have the short cut
option of returning self when copied and then you don't have to muck
with hash or isEqual if you want. For what NSDictionary was mainly
designed for (as a dictionary - strings to values) it makes perfect
sense and it save code for the common uses of the class.
NSSet is about storing only one instance of an object. What "one
instance" means depends on how you have implemented hash/isEqual. If
the default implementation then it is based on a particular instance in
memory otherwise it is based on some aspect of the contents/meaning of
the object.
Nothing is wrong with either NSDictionary or NSSet, they document what
and how the do things (if not that is a documentation bug), you can use
them appropriately or not it is up to you.
The right thing to do, if you want something different then
NSDictionary, is to file a request with Apple for a say an NSMap class
which only retains keys and values (with a comment like you see for
NSSet). Apple could even refactor NSDictionary (and CF) so that it
leverages this new collection class without us caring or knowing.
Complaining about how NSDictionary doesn't act as one may want it to
act is pointless, it will not be changed since many folks depend on it
doing exactly what it is doing. It was a purposeful design decision
made at the time for the task it was designed for.
-Shawn
_______________________________________________
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.