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 23:42:22 +0100
Sure, and that is not a problem. The only requirement is that directly
after
taking the snapshot using 'copy' the objects are considered equal.
There is no such requirement, and your posulating such a requirement
explicitly contradc
When you willingly violate this rule, as you do in your example, you
really
lose all hope of NSDictionary functioning.
Yes but the copying of the keys brings no advantage to the user, and
only adds burden:
(1) if the key is immutable then copying is useless (and often
defaults
to retain anyway)
So this isn't a problem.
Yes it is. Having a mechanism that is useless is not good, especially
if it has negative consequences.
(2) if the key is mutable then
(2a) if its value does not change between storage and retrieval then
copying is useless
Granted. But to just use retain you must know in advance that it won't
change, which may not be easy.
False. If the base implementation of the dictionary just uses retain,
you have two choices:
- if you know that it won't change, do nothing, everything will be fine
and fast
- if you don't know that it won't change, prevent the change (for
example by making a copy)
This can be done in several ways: by the client, by a special method:
-setObject:forCopyOfKey: (which would have the advantage of better
documenting this), or by a special subclass.
If the base implementation uses copy, there is no easy and efficient
way around it.
And if the key then _does_ change by accident
it will result in a hard to find bug.
The key can *still* change when you do the copy, and the bug will be
even *harder* to find because you will think that the -copy prevented
that!
(2b) if its value change between storage and retrieval then you will
not find your object anyway.
This is only true if you use the same instance of the key to retrieve
the
stored object!
How wholly unreasonable! To expect to retrieve an object using the
exact same key! What will they expect next? LOL!
You can create a new key that 'isEqual' to the original one
and retrieve the stored object.
Hmm...just like you can create a copy yourself if there is a need...
On the other hand, if the dictionary only
stores a reference to the key you are indeed in trouble...
Not if it's an identity-dictionary, in which case the value doesn't
matter one bit.
Copying the keys allows you to change the key and still be able to
find the
object.
Only if you have the original key in an unaltered state. In which case
you could should have just used to original key, which would have been
both faster and simpler, and no copying required. Other ideas? :-)
So code like this will work:
#import <Cocoa/Cocoa.h>
int main(int argc, char *argv[] )
{
id pool=[NSAutoreleasePool new];
// funny, is this style catching on?
NSMutableString *key = [NSMutableString stringWithString:@"1"];
-> you have the original key right here, just use it!
id dict=[NSMutableDictionary dictionary];
[dict setObject:@"first" forKey:key];
[key appendString:@"2"];
[dict setObject:@"second" forKey:key];
NSLog(@"first was: %@", [dict objectForKey:@"1"]);
[pool release];
return 0;
}
In my view this makes NSDictionary more robust,
Your view is noted, but you haven't provided any evidence.
but it may not be
everybody's cup of tea. Still, I believe this to be a conscious design
decision, and not a bug.
For the n-th time: just because something is a conscious design
decision does not make it not a design bug.
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.