On Sep 20, 2011, at 02:13 , Torsten Curdt wrote: > Before I was following the docs and wrote the bindings clue code myself > > http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html#//apple_ref/doc/uid/20002373 > > - (void)bind:(NSString *)binding toObject:(id)theObservedObject > withKeyPath:(NSString *)theKeyPath options:(NSDictionary *)options > { > ... > self.observedObject = theObservedObject; > self.observedKeyPath = theKeyPath; > > [theObservedObject addObserver:self > forKeyPath:theKeyPath > options:NSKeyValueObservingOptionInitial > context:nil]; > ... > }
We're fumbling around in the dark here, because Apple doesn't really provide enough information in its documentation. I won't try to assert that the documentation is actively wrong, but it's extremely hard to interpret because it fails to make a distinction between at least 4 different things: 1. Bindings as a general concept -- as a protocol, so to speak. There is documentation on the 'NSKeyValueBindingCreation' informal protocol, but even there there is discussion of specific implementation details that blur the line between what is required by the protocol and what is not. 2. Bindings as implemented in various frameworks classes. Presumably the implementations share certain features and mechanisms -- there are certainly documented regularities in the descriptions, such as the near-ubiquity of a "value" binding -- but there's no certainty that there are really any shared mechanisms in the implementations. (For example, we had a discussion on this list a few months back about the difference between table view column data bindings and popup button menu bindings, where we assumed there was a similar mechanism and therefore similar semantics, but we were completely wrong.) 3. The "for free" implementation of the 'NSKeyValueBindingCreation' protocol in NSObject. Regardless of any impression the documentation may give, it's not there because it's useful generally, it's really there so that NSObject conforms to the protocol. The implementation is presumably used by the frameworks classes, and therefore does what those classes expect. There is no promise that it does what 3rd-party binding designs might need, and there's no reason to force 3rd-party bindings to use the NSObject implementations (that is, *not* to override the NSObject methods). 4. Custom bindings as implemented by 3rd-party classes. This is the subject of the documentation section you linked to above. Note that this *doesn't* refer to the NSObject implementations, and tells you nothing about how frameworks bindings are themselves really implemented. > Now I have found these posts suggesting that it is not required to (or > even one should not) override bind:toObject:withKeyPath:options: > > http://www.tomdalling.com/blog/cocoa/implementing-your-own-cocoa-bindings > http://stackoverflow.com/questions/1169097/can-you-manually-implement-cocoa-bindings > http://stackoverflow.com/questions/366938/is-it-necessary-to-override-bindtoobjectwithkeypathoptions-in-an-nsview-subcl/ AFAICT in a brief glance, these discuss (in effect, because I don't think they untangle ambiguities in the semantics of the term "binding") how to implement custom bindings in the same way that frameworks bindings are (presumed to be) implemented. This involves, obviously, guessing or decoding implementation details, and is as fragile and unsatisfactory as all such practices must be. I believe what you have done is the correct approach. You've implemented a custom binding by consulting the part of the documentation that describes a sample implementation step by step. I don't think it's a good piece of documentation -- it's long on details but short on concepts -- but it's the right piece of documentation. > But I see myself in the same camp: > > When I don't override bind:toObject:withKeyPath:options: my custom > NSView's bindings do not work. It could be something as simple as the NSObject implementation not using the 'NSKeyValueObservingOptionInitial' option that your custom binding apparently requires. You're not obligated to use the NSObject implementation. Quite the reverse -- using it implies that you're bindings are trying to be "compatible" with frameworks bindings at the implementation level, which I'd argue is a pointless exercise. _______________________________________________ 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
