Re: NSSlider and arrangedObjects
Re: NSSlider and arrangedObjects
- Subject: Re: NSSlider and arrangedObjects
- From: Quincey Morris <email@hidden>
- Date: Sat, 21 Jan 2012 16:37:44 -0800
On Jan 21, 2012, at 00:54 , Ken Thomases wrote:
> Table columns do have special handling for array-valued bindings. It's that they distribute the array values among their rows. Table columns are not special in being able to bind through collection properties. That's a feature of NSArrayController.
>
> The table column's bindings still have just an observed object (often the array controller) and a single key path (often of the form "arrangedObject.propertyName"). It's just that, when they receive an array from [observedObject valueForKeyPath:observedKeyPath], they know to pick one element from that array for each row.
I have to speak under potential correction, since I don't have the implementations to refer to, but I don't believe this analysis.
Typically, nothing can "bind through collection properties", because typically a binding involves (along with other things) an observation of the target object on a key path, and trying to set up such an observation will throw an exception. If the "collection property" is not really a collection but a proxy (as you've described "arrangedObjects" to be), then the exception might be avoided, but the resulting observation will be useless because there's no KVO compliance. Specifically, I mean that if the key path is "arrangedObjects.propertyName", propertyName changes to individual objects won't propagate to an observer of the key path, at least not unless the arrangedObjects proxy itself observes every element of the underlying array, which is too horrendous to contemplate.
In fact, it seems to me that logic dictates that table columns bound to something we normally write as "arrangedObjects.propertyName" do *not* observe on that key path. Again I don't know, but my assumption has always been that table columns observe the propertyName attributes of just the objects for rows that are currently visible. That in itself makes table columns "special", and their binding's so-called key path not really a key path.
Furthermore, it also seems to me that logic rules against any idea of the table column implementation *requiring* the construction of the *entire* array of row objects, because table views are virtual in the sense that they only reference the objects they need from moment to moment. Anything else would imply horrendous performance penalties for table views with thousands or millions of rows, but I don't believe there is any such penalty implicit in NSTableView itself.
Putting this another way, I find it hard to believe that table columns ever evaluate '[observedObject valueForKeyPath:observedKeyPath]', because that would seem to require construction of a potentially huge and costly array. I've always assumed that, assuming a so-called key path of the form "someArray.someProperty", table columns only ever evaluate '[[someArray objectAtIndex: rowIndex] valueForKey: someProperty]' for specific values of 'rowIndex', never '[[someArray valueForKey: someProperty] objectAtIndex: rowIndex]'.
Finally, we already know, from discussions on this list in the past, that (given the same key path) there *is* a semantic difference between table column bindings and other bindings to arrays, such as those supplying arrays of menu item titles to NSPopUpMenu. In that case, "arrangedObjects.propertyName" fails to be useful because it indeed behaves like a typical key path in a typical binding, rather than having the special binding behavior of table columns.
_______________________________________________
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