On 2010 Feb 01, at 03:53, Quincey Morris wrote:
> I'd point you to the the documentation:
(This is the quote from "Cocoa Bindings Programming Topics" the
documentation I quoted in my original post.)
> I don't see how this can be clearer that bindings are bidirectional.
Yes. It is clear. And I had always thought that bindings were bidirectional,
based on this documentation. Then, two weeks ago, I noticed that -bind:::only
implemented observer behavior in one direction. I then read *this*
documentation:
> bind:toObject:withKeyPath:options:
>
> "Establishes a binding between a ..."
"Establishes a binding!" So, then, having forgotten the other documentation, I
thought like Matt, that bindings are unidirectional. Until I tried it with an
NSButton.
So now we have this paradox:
1. "Cocoa Bindings Programming Topics" says that bindings are bidirectional.
2. bind:toObject:withKeyPath:options: documentation says it "establishes a
binding"
3. bind:toObject:withKeyPath:options: implementation establishes something
which
is unidirectional.
Choose one of the following explanations:
1. "Cocoa Bindings Programming Topics" is wrong.
2. bind:toObject:withKeyPath:options: documentation is wrong.
3. The use of the word "binding" in "Cocoa Bindings Programming Topics" is
different than the usage in bind:toObject:withKeyPath:options:
documentation. (This would bring the number of definitions Apple
has for the word "binding" up to about 5. A whole 'nother topic.)
4. The implementation of bind::: is incomplete.
5. bind::: does what its documentation says, based on a very critical
legalistic reading, as I explained at the bottom of my second post.
Quincey has explained further that you must override it and to get the
additional "bindings behaviors" and get a complete binding.
Quincey, I believe that you would vote for explanation #5, but it appears that
you have invented a term "bindings link" to refer to the unidirectional binding:
> implementation of 'bind:...' that correctly establishes bindings links for
> behaviors implemented in the frameworks (NS) subclasses.
Could you possibly also support explanation #2?
_______________________________________________
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
