Re: KVO on objects in NSArrayController
Re: KVO on objects in NSArrayController
- Subject: Re: KVO on objects in NSArrayController
- From: Quincey Morris <email@hidden>
- Date: Sat, 03 Sep 2011 00:59:41 -0700
On Sep 2, 2011, at 23:34 , Jerry Krinock wrote:
> Indeed it is, *if* you literally want the notification, as you said in your original post, "whenever the user toggles a … checkbox".
Sure.
> However, if, as is more commonly the case, you actually need a notification whenever the 'marked' attribute in the data model changes, and if your application provides any other means by which that attribute could be changed, such as Undo, scriptability, business logic, or some other view of that attribute, which may be added in the future, then the shortcut of wiring to the control's action, although convenient, is going to be be missing these changes.
I think characterizing it as "more commonly the case" is going too far. If it were really true that the most common KVO case made it desirable to observe thousands of individual objects (as opposed to observing or watching something less numerous), then we'd see a lot more complaining about KVO on this list. :)
I'd say the opposite is true -- the absolute need to observe properties of every individual object in an array (especially a large array) is rare enough that it's not a great hindrance to the usefulness of KVO generally.
Still, in the scenario you raise, where there's a big array and it doesn't seem feasible to observe everything in the array, then I would look for a solution that produces KVO notifications for the array itself. That is, rather than generating a KVO notification for 'array [n].object.property changed', I'd arrange to generate a KVO notification for 'array object at index n was replaced'. (And in fact, I've written code like this. Unfortunately, it's a bit tricky to get it right.)
OTOH, doing this may well fall under the heading of premature optimization. We don't have any a priori reason to assume that setting up tens of thousands of observations is infeasible, or a performance or resource bottleneck.
_______________________________________________
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