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 17:31:44 +0200
On Jun 7, 2004, at 5:00 PM, Shawn Erickson wrote:
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.
It does IMHO, because they are conceptually related. A set is a
dictionary with a boolean "object". A bag or counted set is a
dictionary with an integer "object". NSSet and NSDictionary use the
same algorithms to store and retrieve keys/objects. They must share a
lot in their implementations.
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.
It's clear to everybody that it was a purposeful decision. It does not
make it right, or necessarily a worthy trade off. In practice I don't
consider this such a big deal, and I'm not asking for a change. That is
not a reason not to discuss the implications of this kind of decisions,
to rationalize about them, or to be critical. Foundation is not gospel
and we're hopefully not monks.
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.