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: Charles Srstka <email@hidden>
- Date: Fri, 16 Jun 2017 19:54:10 -0500
> On Jun 16, 2017, at 4:32 PM, Quincey Morris
> <email@hidden> wrote:
>
> On Jun 16, 2017, at 13:48 , Charles Srstka <email@hidden
> <mailto:email@hidden>> wrote:
>>
>> This is incorrect.
>
> It’s incorrect as a 2-way binding, but it works as a pair of so-called 1-way
> bindings, with the proviso that they may need to be unbound manually, to
> prevent reference cycles, which it sounds like is what Jerry is doing.
>
> The thing that I always said that no one believed is that there’s really no
> such thing as 1-way binding, and NSObject’s default implementation of the
> “bind:…” method does *not* establish a binding. It’s *part* of the
> implementation of a proper 2-way binding (as explained in the documentation
> you referenced), and for a given receiver class the method only establishes a
> 2-way binding if it’s an override that provides the rest of the functionality.
>
> But every time I said that (until I stopped saying it about 10 years ago),
> people would jump in and say that the NSObject implementation really does
> establish a binding, and if it’s only one-way, that’s
> just-fine-with-them-thank-you-very-much.
>
> Thanks for the mention of mmalc, BTW. Them were the times. <elderly cough>
The thing is, though… I can’t find the thread anymore, but I distinctly
remember posting some code that used -[bind:::] two ways like that, and getting
chewed out for it. :-P The thing is, NSObject’s implementation of bind is meant
to be part of a two-way bindings mechanism to be fully implemented by a view
object, and it’s not really meant to be called outside of that context—and on
top of that, it’s preferred that bindings go either through an
NSObjectController, an NSViewController, or something else that implements
NSEditorRegistration. Just using using -bind twice both ways between two
arbitrary objects may accidentally work, but it’s not as intended. If all you
want to do is synchronize some properties on two distinct objects, you’re
supposed to use plain old KVO for that (as you mention, the new closure-based
API in Swift is quite nice for doing this). And I did manage to find a quote
for that last bit, by none other than mmalc himself:
https://lists.apple.com/archives/Cocoa-dev/2004//Feb/msg01228.html
<https://lists.apple.com/archives/Cocoa-dev/2004//Feb/msg01228.html>
Charles
_______________________________________________
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