Re: Binding/KVC : valueForKey: and NSDictionary (was: valid accessor for framework objects. (was: implicit and explicit invocation of description method))
Re: Binding/KVC : valueForKey: and NSDictionary (was: valid accessor for framework objects. (was: implicit and explicit invocation of description method))
- Subject: Re: Binding/KVC : valueForKey: and NSDictionary (was: valid accessor for framework objects. (was: implicit and explicit invocation of description method))
- From: Christian Brunschen <email@hidden>
- Date: Wed, 6 Oct 2004 14:13:37 +0100
On 6 Oct 2004, at 11:01, Max Barel wrote:
Self followup, for the record:
A private mail reply suggested that the @count array operator might
work for NSDictionary. IT DOES.
I filled an enhancement request about this. Excerpt:
Ehancement request:
- Modify the -valueForKey: of NSDictionary for it to call
-objectForKey: and if the return value is nil, then resort to the
default -valueForKey: behavior.
I think that behaviour would be potentially *extremely* confusing.
Consider if someone uses NSDictionaries to store key-value-pairs
describing something, which happens to include using the keys
'description' and/or 'count'. Now, consider if the presence of the
values for those keys is optional in the case they are used like that.
The user's expectation is and should be that he can check for the
presence or absence of the values for those keys using
key-value-coding. According to your proposal, though, the user would
get the 'count' and 'description' values from the NSDictionary instead,
which have absolutely no relation to the count and description that the
user himself is putting into these dictionaries.
Essentially, it would preclude the use of the 'count' and 'description'
keys in any NSDictionary that you wanted to use through KVC, because
they don't behave like all the *other* keys do.
I believe that NSDictionary's current behaviour, where the contents of
the dictionary not just override but completely replace what the
default implementation would do, is correct.
You have noted, of course, that keys beginning with '@' are used to
specify 'operators' on NSArrays and on NSDictionaries. These offer a
way to 'talk to' the NSDictionary itself (rather than its contents)
using key-value coding. However, for NSDictionary at least, these are
not sufficiently documented, and thus, your second suggestion,
- Document the specificity of NSDictionary and the @count operator
availability.
is of course excellent.
One might consider if an operator '@self', which would give access to
the dictionary (or array) using the default KVC implementation, might
be useful: Thus, rather than having to specify sn explicit '@count'
operator, one could use the key-path '@self.count' - and that would
work for any method(s) that might be added to arrays, dictionaries, or
other collection classes. Hmmm...
Best wishes,
// Christian Brunschen
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden