Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!)
Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!)
- Subject: Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!)
- From: Marcel Weiher <email@hidden>
- Date: Sun, 6 Jun 2004 14:13:24 +0200
On 5 Jun 2004, at 17:49, Nat! wrote:
Am 05.06.2004 um 16:00 schrieb Marcel Weiher:
First, there is *nothing* whatsoever in the behavior of a dictionary,
in general CompSci terms, that says its keys should be copied. A
dictionary is simply a mapping of keys to values. I have never seen
either a definition of dictionary or an implementation that does the
copying (apart from this one).
The practical reason for copying
You are replying to the theoretical reasoning with a practical
argument, but have snipped the practical reasoning. Anyway...
is, that in 95% of all cases the keys of dictionaries are strings.
And roughly 100% of those will be strings that do not change
afterwards, wether they are constant strings or not. If you design your
class in such a way that it assumes (and almost requires) string keys,
then it should be called a NSStringDictionary. And 95% of all
statistics are made up out of thin air on the spot ;-)
Having mutable objects as keys is of course a pandaras box of errors,
This is a theoretical fear. It isn't an practical problem.
therefore the key gets copied.
You conveniently snipped my analysis of this part, so here it goes
again:
- copying the key is unnecessary, because you can easily specify that
requirement in the contract
- copying the key is unnecessary, because (string) keys typically
won't change, even if they theoretically could
- copying the key does not solve the problem, because copied items can
still change under you
As we know, copy on immutable objects is usually just a retain.
Relying on a property of objects
This retain would have to be done anyway, if you are not copying.
So it is not a design bug but a design choice and a good one.
In a word: no.
It is not a good design choice because it
(a) attempts to solve a problem that DOES NOT EXIST, practically
(and in fact pretty much relies on it not existing in the first
place!)
(b) then goes on to not actually solving the blasted problem
(c) prevents uses of the class that are perfectly legitimate for a
dictionary
(d) where other solutions exist that work at least as well if not
better without introducing these problems
That, to me, is a design bug. A well-intentioned one, no question!
But another one that wasn't thought through.
Second, the definition is a mapping of (object) keys to values. NOT
of the key's value to a value. Since one of the fundamental
properties of objects is that they have identity (See RM-ODP and
other definitions of the term), the fact that a *different* object is
actually used as a key is, at the very least, an odd choice.
By that reasoning you would create two entries for
[dictionary setObject:@"foo"
forKey:[@"bar" mutableCopy]]; // yeah, leak, so what
[dictionary setObject:@"xxx"
forKey:[@"bar" mutableCopy]];
No.
With the current "design", you impose the constraint that copies must
have the same hash and compare equally. Which may not be
desirable/feasible. And it is also not documented, as far as I can
see.
What would that be good for, in the general case ? As the copy will
satisfy the -hash and -isEqual "identity",
Says who?? It certainly isn't listed as a requirement in the
NSCopying protocol. Neither is it listed as requirement in NSObject's
protocol documentation. In fact, NSObject's implementations -hash and
-isEqual: do not satisfy this "identity" you have conjured up out of
thin air.
On the other hand the following appears in -hash:
If a mutable object is added to a collection that uses hash values to
determine the objects position in the collection, the value returned
by the hash method of the object must not change while the object is in
the collection. Therefore, either the hash method must not rely on any
of the objects internal state information or you must make sure the
objects internal state information does not change while the object is
in the collection. (Note that it can be difficult to know whether or
not a given object is in a collection.)
This actually blatantly contradicts the implementation in NSDictionary!
the copy is just as good as the original for the purpose.
No.
In cases where you want more control or true object mapping based on
address equality, you will probably use NSMapTable.
Yes, I am forced to do this due to the fact that NSDictionary is
inadequately designed.
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.
| References: | |
| | >Ugly bug in Foundation, beware! (From: Ondra Cada <email@hidden>) |
| | >Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Alastair Houghton <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Ondra Cada <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Alastair Houghton <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Brent Gulanowski <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Alastair Houghton <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Ondra Cada <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Marcel Weiher <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Brent Gulanowski <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: "Louis C. Sacha" <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Marcel Weiher <email@hidden>) |
| | >Re: Is that really a bug at all? (was: Re: Ugly bug in Foundation, beware!) (From: Nat! <email@hidden>) |