Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional?
Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional?
- Subject: Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional?
- From: Quincey Morris <email@hidden>
- Date: Mon, 1 Feb 2010 03:53:45 -0800
On Jan 31, 2010, at 19:03, Matt Neuburg wrote:
> There's a common misconception here, and I see a lot of nonsense written
> about it, to which I with difficulty restrain myself from responding. It's
> all very simple.
>
> (1) There is no such thing as a bidirectional binding; all bindings are
> unidirectional. If you want a bidirectional binding, set up two bindings so
> that you bind in both directions (there is nothing wrong with this, the
> computer doesn't explode or anything like that).
>
> (2) But some objects, most notably built-in interface objects, when they are
> told to bind, also set up KVO so that information runs back the other way.
> You can emulate this in your own interface objects, and mmalc has a
> wonderful example that shows you how to do it (and, by implication, shows
> you how the built-in interface objects are doing it).
As a writer of what you apparently see as "nonsense", I'd suggest that you might want to substantiate claims like (1) and (2), if you can. However, they seem to me to be flat-out false.
I'd point you to the the documentation:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html#//apple_ref/doc/uid/20002372
> "What Is a Binding?
>
> "A binding is an attribute of one object that may be bound to a property in another such that a change in either one is reflected in the other."
and:
> "Key-Value Binding
>
> "A binding is established with a bind:toObject:withKeyPath:options: message which tells the receiver to keep its specified attribute synchronized—modulo the options—with the value of the property identified by the key path of the specified object. The receiver must watch for relevant changes in the object to which it is bound and react to those changes. The receiver must also inform the object of changes to the bound attribute. After a binding is established there are therefore two aspects to keeping the model and views synchronized: responding to user interaction with views, and responding to changes in model values."
I don't see how this can be clearer that bindings are bidirectional.
Further, the two directions are *not* precisely symmetrical, so you cannot in general "emulate" bidirectional behavior with two "unidirectional bindings". For example, a NSButton does not have a "value" KVC property, but it does have a "value" non-KVC attribute. You can bind *from* "value", but not *to* "value".
What you're referring to, I believe, is that the current behavior of -[NSObject bind:...], *when used in isolation* and *when specifying in its first parameter an attribute that happens to be an actual KVC property of the bound-from object*, is to transmit the value of the bound-to property to the bound-from property. That's certainly unidirectional, but it isn't a binding -- in the sense of being a complete binding behavior. Further, that isn't *the* implementation of the NSKeyValueBindingProtocol method, but *an* implementation.
It's also worth noting that although NSObject implements NSKeyValueBindingProtocol, it doesn't actually implement any binding behaviors. Those are all implemented in subclasses with additional code. What NSObject does is to provide a implementation of 'bind:...' that correctly establishes bindings links for behaviors implemented in the frameworks (NS) subclasses. Any use of NSObject's implementation outside of these criteria does not seem safe (I would claim) in terms of the API contract, even if we think we know how the current implementation works.
_______________________________________________
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