Re: Can a subclass of NSDictionary do this?
Re: Can a subclass of NSDictionary do this?
- Subject: Re: Can a subclass of NSDictionary do this?
- From: p3consulting <email@hidden>
- Date: Wed, 23 Jul 2003 23:14:33 +0200
>
On Wednesday, July 23, 2003, at 02:29 AM, p3consulting wrote:
>
> NSKeyValueCoding is limited in functionality for general use
>
>
Not really, it's exceptionally useful for "general use." Just because
>
it doesn't cover 100% of the features it would be nice to have doesn't
>
mean it's useless. :)
Where do you read "useless" in the original post ?
limited != useless
and "not covering 100% of the features" = limited.
>
>
> (WebObject/EOFramework origin ?), for example in doesn't support array
>
> in the path syntax
>
> (e.g. "a.b[1].c")
>
>
This would be useful in some cases, though I haven't really felt a
>
burning need for it in all the Cocoa development I've done. The
>
scripting extensions to KVC would certainly support the addition of
>
array access to the key-path parser.
>
>
> and the takeValue:forKeyPath: doesn't create the
>
> intermediary path items if they don't already exist
>
> (ok this should be a parameter)
>
>
This would generally be a bad idea.
"bad idea" ? this is just a subjective opinion
in the strict context of KVC related to scripting probably,
but as an extension to NSDictionary and NSMutableDictionary:
- (id)objectForKeyPath:(NSString *)inKeyPath;
- (void)setObject:(id)inValue forKeyPath:(NSString *)inKeyPath;
may find some use, especially for the one asking the question at first
place:
it was a little bit related to preferences handling not scripting
>
How would KVC know (a) what types
>
of intermediate path items to create and (b) how to go about creating
>
them (i.e. what the designated initializer is etc.)?
by definition intermediate path items class is derived from the path
expression
(in the context of NSDictionary extensions - NOT of KVC related to
scripting of course)
a.b.c -> implies a and b are NSDictionary, c can be anything
a.b[1].c -> a is a NSDictionary, b is NSArray , c can be anything
a.b[0][2].c -> a is a NSDictionary, b is NSArray , b[0] is NSArray,
b[0][2] is a NSDictionary, c can be anything (nothing can be said of
b[0][0] and b[0][1])
since they are susceptible to be modified they must be of the mutable
type
When adding b[4] before b[0]b[3], we could set b[0] to b[3] to [NSNull
null].
Just a question of conventions here
Anyway objectForKeyPath and seObjectForKeyPath are just about 60 lines
of code (in a not-thread save version) not a big deal
Pascal Pochet
P3 Consulting
email@hidden
http://www.p3-consulting.net
_______________________________________________
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.