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: Nat! <email@hidden>
- Date: Sat, 5 Jun 2004 17:49:51 +0200
Am 05.06.2004 um 16:00 schrieb Marcel Weiher:
On 4 Jun 2004, at 19:59, Louis C. Sacha wrote:
The collection classes in Cocoa are defined to work in a specific
way, and have a relatively clear "contract" regarding how they work.
While some people disagree with how NSDictionary and NSArray are
implemented, the way that copy is implemented for those classes is
"correct" in terms of their "contracts".
That just means that they documented it correctly, not that it isn't
broken. As I've said before, NSDictionary's copying the key is a
*design* bug, not an implementation bug.
Here's a somewhat more detailed analysis on why NSDictionary's
behavior of copying the key is wrong as implemented.
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 is, that in 95% of all cases the keys
of dictionaries are strings. Having mutable objects as keys is of
course a pandaras box of errors, therefore the key gets copied. As we
know, copy on immutable objects is usually just a retain. 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.
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]];
What would that be good for, in the general case ? As the copy will
satisfy the -hash and -isEqual "identity", the copy is just as good as
the original for the purpose.
In cases where you want more control or true object mapping based on
address equality, you will probably use NSMapTable.
Ciao
Nat!
------------------------------------------------------
Opposites attract.
Then they kill each other. -- Conley
_______________________________________________
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>) |