There's a design flaw here somewhere, but I can't quite figure out what it is. It's highlighted by trying to reorder widgets. With KVC to-many relationships, there's no atomic way of moving an object from one position in an array to another : you remove the object, then re-insert it at the new location. But when the object is (temporarily) removed from the array, the window controller gets an observeValueForKeyPath saying it's been deleted, and so releases the corresponding WidgetViewController, the view gets deallocated, and so on. I'll then get a second observeValueForKeyPath saying that an object has been inserted, recreate the WidgetViewController, re-insert the view, etc etc.
That’s not a design flaw, but rather just a shortcoming of the KVO change model. Note that NSMutableArray has no operation to move an object from one index to another, either.
This seems pretty wrong to me. I can see a few workarounds (perhaps storing the kvo notifications until the end of the current runloop so I can add them together and figure out what was really a deletion and what was just a reordering), but they all seem pretty ugly and heavyweight.
The runloop batching is probably the best thing to do if you’re concerned about the cost of reordering views, or if you want to animate the change in some way. If you just need to atomically rearrange the view, you might be able to get by with a pool of recently-deallocated WidgetViews and WidgetViewControllers that you reuse when you get a new object insertion (avoiding the allocation overhead).
-Ben_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
