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: Marcel Weiher <email@hidden>
- Date: Mon, 7 Jun 2004 17:42:12 +0100
On 7 Jun 2004, at 16:31, Marco Scheurer wrote:
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.
And right you are.
A set is a dictionary with a boolean "object".
Well, that's one way of looking at it. Another way is that a
dictionary is a set of associations, with each association being a
single key -> value mapping. A bag is then an association key ->
collection. In fact, this is how most Smalltalk implement
dictionaries. Incidentally, there is also nothing intrinsically in a
dictionary that requires hashing...
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.
Neither am I, by the way. Though a NSGenericDictionary as superclass
of NSDictionary, implementing just the retain would be nice.
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.
Precisely. Would those who think it *is* gospel and whose only
response is "it's documented so it is right" please stop repeating
that?
Anyway, this copying behavior is really just another symptom of the
ill-fated attempt to bring "value" semantics to the "objects" side of
Objective-C (the numbers subset of C has it). All of these attempts
must ultimately fail, and will cause the kinds of inconsistencies we
have been seeing as well as dragging performance down quite
substantially.
The (very abridged) reason why they *must* fail is that the only way to
actually get value semantics (referential transparency / the kinds of
guarantees NSDictionary fools you into thinking it has but can't
actually keep ) is to have no mutable state. At all.
There is a whole branch of computing that *does* work this way, and
it's been a long while coming, and requires dedicated languages, with
smart compilers to make them run at least somewhat reasonably.
The hope that you can get all of that by just adding a few subclasses /
methods in an imperative, pointer-based language like Objective-C is
pure fantasy. Hopelessly naive fantasy. Of course, if you *do* pull
it off, there is probably a Turing Award waiting for you somewhere.
But don't hold your breath.
In the meantime, thinking that you *do* have or can achieve this
property just leads to inconsistencies, false expectations, bizarre
coding like Ondra's "single password scheme" and general inefficiency.
So: we have an imperative language. We have mutable state. Deal with
it. Be *aware* of it and especially of where/when that state will be
mutated and needs to be preserved. Don't pretend you can make that
fact or those decisions go away with strange accessors or strange
dictionary implementations, because you can't. Thinking that you can
will come back and bite you, for example by giving all your users the
same password ;-)
Cheers,
Marcel
_______________________________________________
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.