On Jan 25, 2009, at 13:20, Jeff Johnson wrote:
If you want to implement the getter xxxx, then you don't need to
implement countOfXxxx and objectInXxxxAtIndex:. Since your backing
store is not an array, the implementation of the getter should
create and return an array. In the docs for KVC compliance, it says
that you should implement the getter OR implement the indexed
accessors.
http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/Compliant.html
I *do* want to implement the getter (thereby gaining both KVC
compliance and convenience). I *don't* need, therefore, the indexed
accessors to provide KCV compliance, but I *do* need the indexed
accessors to support the behavior of an array proxy.
Having both getter and indexed accessors doesn't break KVC compliance,
it just breaks the ability for code to create a proxy, which is an
entirely different matter. (The proxy is, after all, a kind of
NSArray, so returning it from the getter would also be KVC-compliant.)
And I do want to return the proxy from my getter. Returning a
"genuine" NSArray is not really an option. I'm not really talking
about a single property -- there are lots of possible properties
spread across lots of classes. Their storage and performance
characteristics are not known in advance, nor is it even known if they
have indexed accessors or not.
The NSArray proxy is the perfect wrapper for all these implementation
details. The only problem is that I can't actually create it, because
the only apparent way to do that is to call valueForKey:, and the
presence of the getter makes that call mean something different.
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
