Re: NSSlider and arrangedObjects
Re: NSSlider and arrangedObjects
- Subject: Re: NSSlider and arrangedObjects
- From: Ken Thomases <email@hidden>
- Date: Sun, 22 Jan 2012 11:40:08 -0600
On Jan 21, 2012, at 6:37 PM, Quincey Morris wrote:
> 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.
Go ahead and try it. Instantiate an array controller and set up key-value observation on a key path which goes through its arrangedObjects property. No 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.
It's not so horrendous. It's what one is encouraged to do with one's own code if one needs to observe properties of the elements of a collection. You observe the collection property itself to learn when elements are added or removed, and you observe the properties of the individual elements to learn when they change. What do you think the -[NSArray addObserver:toObjectsAtIndexes:forKeyPath:options:context:] method is for?
> 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.
Well, the actual implementation is of course hidden. However, there's nothing preventing it from using KVO on arrangedObjects.propertyName. If it does otherwise, it is just an optimization.
> 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.
It is already necessary to "construct" the entire array of objects to know a) how many objects are in the table, and b) which objects belong to which rows in the face of sorting. And, again, you're now talking about optimizations, not any requirement imposed by what can or can't be key-value observed.
> 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]'.
Again, you're guessing at optimizations.
> 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.
The difference with pop-up menus is just whether or not the view understands a key path which returns an array. I agreed in my earlier email that table columns are "smart" in that way. For a key path which returns an array, they pick out individual elements for individual rows, which other views don't do. Doesn't impact on the question of whether or not it's possible to bind or key-value observe through the arrangedObjects property of an array controller.
You contend that table views are special. What about this? You can bind a text field's value to email@hiddenrtyName. You can bind any view's enabled, editable, or hidden binding to the same sort of key path. Was every one of those cases special-cased? Can any of those bindings be implemented without actually observing the propertyName property of every object within the collection?
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