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:56:03 +0100
On 7 Jun 2004, at 22:43, Patrick Machielse wrote:
op 07-06-2004 14:20 schreef Alastair Houghton
The fundamental point is that it doesn't make any sense whatsoever for
MyObject *obj = [[MyObject alloc] init];
NSMutableDictionary *dict = [[NSDictionary alloc] init];
[dict setObject:@"Hello" forKey:obj];
NSLog (@"%@", [dict objectForKey:obj]);
to do anything other than display "Hello" on the console.
[]
No response here? Can you be more specific? Do you think it *makes*
sense for this to display anything other than "Hello"?
MyObject fulfils all of the requirements stated for -isEqual: and
-hash, and
it is the *NSDictionary* that is storing a different key to the one
that it
was given, *not* the user.
The code above will work for a well designed key class. It is the user
that
broke the implicit 'copy is equal' contract for MyObject.
NSObject is not well designed? I could have easily made the example
work with NSObject by adding a category that supports NSCopying.
It seems you are saying that everything in the entire system must be
designed to satisfy the whims of a somewhat whacky dictionary
implementation, namely NSDictionary. While that is a position you can
take, similarly to the (supported by both Newtonian and Einsteinian
relativity) idea that the entire Universe revolves around you, just in
somewhat complicated orbits, I don't think it is a defensible position.
You can consider isEqual: whatever you like, as long as you obey the
implied
rule:
when b = [a copy] then [b isEqual:a] == YES must hold
If the only thing about the object is its existence---i.e., if it
doesn't actually have any instance data---then it makes a great deal
of
sense for a -copy'd object to break the rule you propose.
I don't propose this rule. You can deduce it from the documentation of
NSDictionary.
What if I don't use NSDictionary? Is the class then still badly
designed? Does it suddenly become badly designed if I then start using
NSDictionary? Do you see a pattern?
If I have this particular implementation of NSDictionary, there is a
problem. If I don't, no problem. (Compare NSSet). A reasonable
conclusion would be that NSDictionary is at the heart of the problem.
There are uses for these types of object; for instance, they could be
used to
provide a unique identifier without requiring additional unnecessary
storage,
or they might be used as some sort of NULL value, perhaps to mark the
boundaries of a data structure or to provide a particular set of
semantics in
an expression that has been built into a parse tree of objects.
This may be true, but if you design objects like this you just can't
use
them as dictionary keys.
PRECISELY. But only because of this somewhat whacky, and highly
untypical, implementation of a dictionary. So this dictionary has a
limitation in that I can't use perfectly reasonable kinds of objects
with it. All to not fix a non-problem, for which other fixes are
easily possible, while the problems with the current design aren't
fixable as easily.
Clearer now why someone might consider this a design bug, when an
alternative design would have provided effectively the same benefits
without the problems?
This may be a disadvantage to some. However, in any
of these cases it is probably easy to change the objects' designs such
that
they _can_ be used as keys.
Once again, you are saying that a potentially unbounded number of
objects should be modified to adapt to the whims of *one* whacky
implementation. Again, all to not fix a non-problem when there are
plenty alternatives that would have effectively the same benefits
without having all these negative side effects.
But only because NSDictionary places additional constraints on
-isEqual: and -hash that Marcel and I contend are unnecessary and
prevent some otherwise legitimate uses of the NSDictionary class.
I think it only places a constraint on -isEqual: namely that 'copy'
creates
two equal objects. This is indeed an extra consideration when
designing an
object that will be used as a dictionary key. I don't see how this
impaires
the usefulness of NSDictionary though.
Certain objects cannot be used. I would think that "can be used" would
be essential to any reasonable definition of "usefulness". So "cannot
be used" is, per definition, am impairment of the usefulness of the
dictionary.
Hmm...
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
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.