Re: Release mode bindings crash and release pools
Re: Release mode bindings crash and release pools
- Subject: Re: Release mode bindings crash and release pools
- From: Quincey Morris <email@hidden>
- Date: Fri, 16 Jun 2017 10:35:34 -0700
On Jun 16, 2017, at 08:15 , Jerome Krinock <email@hidden> 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 (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