> On Dec 20, 2017, at 4:23 AM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > >> The original code used all the same three array controllers, with the exact >> same subclassing of the target's one. > > This is where I take the fifth. > > When bindings were introduced, back in 10.3 or 10.4, then refined in 10.5, it > looked very much like Apple was trying to sell a sort of data-manipulation > “language” constructed out of bindings and NS…Controller classes. While this > worked great for pushing glue code out of .m source files and into .nib files > (this predated .xib files), it’s was too general, too inscrutable and too > clumsy to have much wider appeal. In effect, the whole thing with bindings > died at 10.5, except for the part where they were used within IB to hook up > specific controls to specific properties. That part is really all we use > today.
That’s going a little far, isn’t it? I still find bindings/KVO useful for a lot of cases where I want to keep things synced. For example, in Pacifist I have a main outline view, and a search results table on the side (currently in a drawer, although that’s changing in the currently-under-development Swift rewrite). The selected item in the search results and in the main outline view should always be the same, and I do that by setting things up, via a system of computed properties and keyPathsForValuesAffecting<key> methods, so that the table’s selectionIndexes and the outline’s selectionIndexPaths are both essentially backed by the same underlying property. The result is that not only does it update the selection in the outline view when you change the selection in the search results, as you’d expect, but it also manages to update the selection in the *search results* if you select an item in the main outline view that happens to also be a search result. A big deal? No, but it’s one of those little details that makes an old Mac geek like me smile. ;-) I doubt I would have gone to the trouble of making it do that if I’d had to write the glue code manually. Charles _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
