Improved NSDictionary behavior (was: Re: NSDictionary design bug (was: Re: Ugly bug in Foundation, beware!))
Improved NSDictionary behavior (was: Re: NSDictionary design bug (was: Re: Ugly bug in Foundation, beware!))
- Subject: Improved NSDictionary behavior (was: Re: NSDictionary design bug (was: Re: Ugly bug in Foundation, beware!))
- From: Kyle Moffett <email@hidden>
- Date: Mon, 7 Jun 2004 20:40:56 -0400
On Jun 07, 2004, at 15:13, Christian Brunschen wrote:
3) Let The Object Decide
By introducing a new protocol, I'll call it 'NSDictionaryKey' for this
discussion, each object could be asked for the correct behaviour -
whether
to use the object directly, whether the object needs to be copied, and
so
on. Something like this:
Why not something more general, like "NSKey" or "NSMappingKey." Then
this same method could be used for other places where one wants to store
an immutable value representing the current state of an object. The
general
behavior for some mutable object with a complex state would be to
return an
NSData or NSString of some kind with the important parts represented.
@protocol NSDictionaryKey
- (id) replacementKeyForDictionary:(NSDictionary *)dict;
@end
Let's make the same method usable for other non-Apple sets/mappings too.
@protocol NSMappingKey
- (id) replacementKeyForObject:(NSObject *)object;
@end
[... Sample implementations for mutable vs. immutable objects ...]
... and any class of the developer's own devising could do exactly
what it
wanted. The object returned by 'replacementKeyForDictionary:' would
still
have to obey the rules about being equal to the object it is a
replacement
for; i.e., it would still have to return the same value from -hash, and
'[[foo replacementKeyForDictionary:dict] isEqual:foo]' would have to
return YES.
So a totally ignorant object would just inherit the desired behavior
depending
on the APIs that it already implements, while an object that knows
about the
API can do the proper thing in all circumstances.
By adding this method to NSObject, all subclasses of NSObject would
inherit this method and would continue to work as before, as this would
make all objects that conform to the NSCopying protocol use, by
default, a
copy of themselves as the replacement key. This duplicates the
behaviour
of the current implementation, so everything would continue to work
undisturbed.
As long as the NSMutable* classes are fixed to have proper
implementations.
So basically, my suggestion is that implementing something like the
third
approach above would essentially resolve the issue in a way that should
make everybody reasonably happy: It would remove the automatic copying
of
keys, and it would allow each class, indeed each individual object, to
specify another key to use in its place if warranted - specifically for
those cases where someone attempts to use a mutable object as a key in
a
dictionary. And all while not breaking any existing code.
Yay!!! World peace!!! Err, maybe not, but at least Marcel and Ondra can
stop
fighting and get back to coding, which I'm sure they'll be quite happy
to do :-D
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a17 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
_______________________________________________
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.