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: Sat, 17 Jun 2017 10:36:50 -0500
> On Jun 17, 2017, at 8:36 AM, Jonathan Mitchell <email@hidden> wrote:
>
>> On 17 Jun 2017, at 14:21, Charles Srstka <email@hidden
>> <mailto:email@hidden>> wrote:
>>
>>> On Jun 17, 2017, at 5:32 AM, Jonathan Mitchell <email@hidden
>>> <mailto:email@hidden> <mailto:email@hidden
>>> <mailto:email@hidden>>> wrote:
>>>
>>>> On 16 Jun 2017, at 23:18, Quincey Morris
>>>> <email@hidden
>>>> <mailto:email@hidden><mailto:email@hidden
>>>> <mailto:email@hidden>>> wrote:
>>>>
>>>> On Jun 16, 2017, at 14:41 , Jonathan Mitchell <email@hidden
>>>> <mailto:email@hidden> <mailto:email@hidden
>>>> <mailto:email@hidden>>> wrote:
>>>>>
>>>>> I sometimes use the default NSObject bind: to set up a simple one way
>>>>> operation as you describe as opposed to a discrete observation.
>>>>
>>>> With macOS 10.13, the new block/closure-based KVO “addObserver” method is
>>>> probably an easier way, although you do have to remove it manually.
>>>>
>>> The block/closure improvements are long overdue IMHO.
>>>
>>> I use a home brewed approach using BPBlockValueTransformer :
>>> NSValueTransformer with bindings that gives a lot more flexibility.
>>> A trivial example involving a closure would be:
>>>
>>> BPBlockValueTransformer *blockValueTransformer = [BPBlockValueTransformer
>>> valueTransformerWithBlock:^id(NSNumber *value) {
>>> strongify(self);
>>> return ([value boolValue] || self.isFree)? @“Freedom for all" :
>>> @“Freedom for no-one";
>>> }];
>>> [self.titleTextField bind:NSValueBinding toObject:self.repObjCon
>>> withKeyPath:@"selection.isHidden" options:@{NSValueTransformerBindingOption
>>> : blockValueTransformer}];
>>>
>>> The downside is that you cannot establish the binding in the NIB.
>>
>> It’s definitely overdue; I’ve been using a blocks-based wrapper around KVO
>> for years.
> Is that a publicly available wrapper?
No, sorry; I probably should have released it, but it's just something I’ve
been keeping around for internal use. If it’s any consolation, it’s pretty much
obsolete now thanks to the new built-in observation support. ;-)
It did have one nice feature that the built-in functionality doesn’t have,
which was a method to catch exactly one change in a certain key path, and after
that change occurred, it would automatically tear itself down. This was pretty
handy for adding “completion handler” support to objects that only let you know
they were finished by setting an observable “done” property. Maybe if I decide
that feature’s still relevant, I’ll port it to the new Swift key path
functionality, I dunno.
>> A couple of notes, though, re-reading the message this replied to. The new
>> blocks-based API, ‘observe()’, is actually part of the Swift overlay, which
>> means it works on older macOS versions, not just 10.13. Also, you don’t have
>> to remove it manually, and that’s in fact one of its major features—it
>> automatically deregisters itself whenever the observer falls out of scope.
>> So as long as you make sure you don’t set up a retain cycle with captured
>> values, you can just stash the observer in an ivar, and when your object
>> gets deallocated, your observer will be unregistered. Much easier than what
>> we had to do before.
> It would be good if I could get this to work all the way back to 10.9 (that’s
> my deployment target).
>
> Accurately managing observation and object lifetimes is such a big time sink
> that any improvement is always welcome.
Just tested it on 10.9; it works :-)
import Foundation
class C: NSObject {
@objc dynamic var foo = "Foo"
}
let c = C()
let observer = c.observe(\.foo) { obj, _ in
print("Foo changed: now it's \(obj.foo)")
}
c.foo = "Bar"
Running it on my Mavs VirtualBox VM, this outputs:
$ ./kvotest
Foo changed: now it's Bar
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