Re: Binding of invisible controls: is lazy data loading possible?
Re: Binding of invisible controls: is lazy data loading possible?
- Subject: Re: Binding of invisible controls: is lazy data loading possible?
- From: Ken Thomases <email@hidden>
- Date: Wed, 21 Jan 2009 00:31:18 -0600
On Jan 19, 2009, at 11:07 PM, Quincey Morris wrote:
If the to-many related objects are mutable, and the -<key> method
does not return an NSMutableArray, you must also implement -
insertObject:in<Key>AtIndex: and -removeObjectFrom<Key>AtIndex:.
[...]
It also suggests that if the -<key> method *does* return a
NSMutableArray, you don't have to implement insert/remove methods
but the property is still KVO-compliant for changes. (I believe I
have code that actually relies on this, and that it does work, but I
would have to go searching for it to be sure.) This is not said
anywhere else (not in the mutableArrayValueForKey documentation, nor
in NSKeyValueCoding.h), and actually contradicts part of what Ken
Thomases said earlier in the thread. So that's yet another puzzle.
The above sentence says that, if the -<key> method returns an
NSMutableArray, then the to-many relationship property is KVC
compliant, not necessarily KVO compliant. I assume that modifying
such a property _using KVC_ (via the proxy returned by -
mutableArrayValueForKey:) would in fact produce KVO change
notifications. You're right; I did fail to mention that as an
exception in my earlier message. However, if I had, it would have
gone in the same parenthetical as +accessInstanceVariablesDirectly.
You should pretend that exception doesn't exist because you should
never return an NSMutableArray for a to-many property. It's an even
bigger hole in encapsulation than +accessInstanceVariablesDirectly --
bigger because one can mutate the array directly, in an off-hand way,
without using KVC.
So, just never do that, and you don't have to worry about what
implications might flow if you did do it.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden