Re: Bindings; Was: whether property in Cocoa class is KVO-compliant?
On 2010 Jan 11, at 03:47, Quincey Morris wrote: On Jan 10, 2010, at 19:58, Jerry Krinock wrote: toObject:segmentedControl You *didn't* bind an NSSegmentedControl to its window controller, you actually bound a window controller['s foo binding] to [the selectedSegment property of] a NSSegmentedControl. Oops, you're correct. Like the method says, bind:*to*:segmentedControl. IIRC the bindings documentation isn't clear which direction is bound to refers to and/or it gives the impression that a binding is symmetric (which it may effectively be at the level of notifications, but it isn't at the level of establishing bindings between objects). When I first heard the word binding, from other uses in English, I assumed that it was two-way, and labored under this incorrect assumption for quite awhile. Now I know that a binding is only one way, and further that change data flows in the *opposite* direction of the *to*. That is, if I bind myself *to* you, I observe what you do and your changes flow back *to* me. I wonder why bindings was not as an extension of KVO, instead of as a separate sideshow. The effect is the same as KVO, with the addition that a designated setter is automatically invoked in the observer when a change is observed. And then there's the whole thing about the separate namespaces for bindings and properties, not to mention the three definitions of the word binding to mean 1. (verb) the act of binding 2. (noun) the connection that you get when you make a binding 3. (noun) the name of the property that gets bound in the receiver I wrote a little document for myself where I actually use the words binding(1), binding(2) and binding(3). Scott, if I ever get to point that I think I know what I'm talking about, I might file a bug to suggest that the whole Cocoa Bindings Reference be destroyed and its pages page added as a Bindings section to the regular API documentation of the bound classes. Thanks for the discussion. I hope I didn't make any more bind mistakes in the above! ___ 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 arch...@mail-archive.com
Re: Bindings; Was: whether property in Cocoa class is KVO-compliant?
On 11 Jan 2010, at 17:01, Jerry Krinock wrote: On 2010 Jan 11, at 03:47, Quincey Morris wrote: On Jan 10, 2010, at 19:58, Jerry Krinock wrote: toObject:segmentedControl You *didn't* bind an NSSegmentedControl to its window controller, you actually bound a window controller['s foo binding] to [the selectedSegment property of] a NSSegmentedControl. Oops, you're correct. Like the method says, bind:*to*:segmentedControl. IIRC the bindings documentation isn't clear which direction is bound to refers to and/or it gives the impression that a binding is symmetric (which it may effectively be at the level of notifications, but it isn't at the level of establishing bindings between objects). When I first heard the word binding, from other uses in English, I assumed that it was two-way, and labored under this incorrect assumption for quite awhile. Now I know that a binding is only one way, and further that change data flows in the *opposite* direction of the *to*. That is, if I bind myself *to* you, I observe what you do and your changes flow back *to* me. I wonder why bindings was not as an extension of KVO, instead of as a separate sideshow. The effect is the same as KVO, with the addition that a designated setter is automatically invoked in the observer when a change is observed. What makes you say this? Bindings do work by using KVO. The default implementation calls -setValue:forKey: when it detects a change, but any object is free to handle a binding any way it likes. (Most of AppKit as far as I can tell uses a customised process that doesn't retain the target object).___ 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 arch...@mail-archive.com
Re: Bindings; Was: whether property in Cocoa class is KVO-compliant?
On 2010 Jan 11, at 09:46, Mike Abdullah wrote: I wonder why bindings was not as an extension of KVO, instead of as a separate sideshow. The effect is the same as KVO, with the addition that a designated setter is automatically invoked in the observer when a change is observed. What makes you say this? Because when bindings observes a change, it uses KVO *and* invokes a special observer method, as you note ... Bindings do work by using KVO. The default implementation calls -setValue:forKey: when it detects a change, but any object is free to handle a binding any way it likes. Well, I guess I'm talking about the default implementation then. I just mean I'd probably have an easier time learning bindings if they were called maybe KVO Plus, and somehow used a class' regular properties on both ends of a binding, instead of defining this separate bindings namespace with definitions that often duplicate the regular properties. ___ 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 arch...@mail-archive.com
Re: Bindings; Was: whether property in Cocoa class is KVO-compliant?
On Jan 11, 2010, at 9:01 am, Jerry Krinock wrote: I wonder why bindings was not as an extension of KVO, instead of as a separate sideshow. The effect is the same as KVO, It's not at all. Bindings uses KVO to ensure that things are kept synchronised; KVO is a general mechanism that allows one object to receive a notification when the value of a property changes. What it does in response is entirely up to it. mmalc ___ 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 arch...@mail-archive.com
Re: Bindings; Was: whether property in Cocoa class is KVO-compliant?
On Jan 11, 2010, at 10:04, Jerry Krinock wrote: Well, I guess I'm talking about the default implementation then. I just mean I'd probably have an easier time learning bindings if they were called maybe KVO Plus, and somehow used a class' regular properties on both ends of a binding, instead of defining this separate bindings namespace with definitions that often duplicate the regular properties. My *guess* is that bindings were originally intended to use properties on both ends (note that the -[NSObject bind: ...] documentation *still* says this), but developed from there so that one end was something more general with its own namespace. To me, the Cocoa Bindings Reference document reads as if it were written under this incorrect assumption, and then not-quite-thoroughly corrected later. That's one piece of documentational obscurity. Binding *are* bi-directional, in the general sense that they're supposed to allow a property value to be modified from either end of the binding. However, the individual frameworks technology pieces from which bindings are constructed are all uni-directional. That's another piece of documentational obscurity. I only recently figured out that Cocoa binding != binding: although all Cocoa bindings are bindings, not all bindings are Cocoa bindings. That's a third piece of documentational obscurity -- although the fact that it took me 2 years to figure it out possibly reflects badly on me rather than the documentation. I now believe that Cocoa bindings are distinguished by (amongst other things) special (meaning, going beyond KVC) handling for key paths involving NSController objects, although this is undocumented apart from the occasional hint. More documentational obscurity. ___ 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 arch...@mail-archive.com
