On Jun 16, 2017, at 08:15 , Jerome Krinock <je...@ieee.org> wrote: > > Typically the only reason you would explicitly unbind an object is if you > modify the user interface programatically and want to remove a binding. If > you change an objects binding’s values it should first clear any preexisting > values. > > If you implement a custom view or controller with custom bindings, you should > ensure that it clears any bindings before it is deallocated—in particular it > should release any objects that were retained for the specified binding in > the bind:toObject:withKeyPath:options: method and should deregister as an > observer of any objects for which it registered as an observer. It may be > convenient to implement this logic in an unbind: method that you then call as > the first step in dealloc. > > # # # # > > I’m confused. The first paragraph says not to worry about it, and the second > says, well, maybe you do.
I doubt this is ever going to be cleared up. The document you refer to was written for Tiger (look at the screenshot of the Bindings inspector), so around 2004. Although it’s been slightly updated several times since, the updates have been un-substantial, and I swear the last time an Apple documentation writer actually understood bindings was about 2005. Still… The first paragraph is talking about invoking “unbind:” on a UI object *when the object is not being deallocated*. The second paragraph is talking about “clearing” bindings when the bound object is deallocated. It’s just saying you need to ensure you didn’t create any retain cycles, and remove KVO observations, and suggesting you might encapsulate this cleanup in an “unbind:” method. It’s not (AFAICT) actually talking about unbinding anything in any more formal sense (although if you did it wouldn’t be wrong). Part of the conceptual problem is that the kinds of bindings described in the document you linked to are bi-directional bindings. The kinds of bindings established by “bind:name:object:keyPath:options” are only uni-directional, and it takes additional custom code (like in the joystick example) to implement the other direction. At least, that’s what I’ve been saying for years, though I don’t think I’ve ever found a developer who believes me. _______________________________________________ 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