> On Jun 17, 2017, at 5:32 AM, Jonathan Mitchell <li...@mugginsoft.com> wrote: > >> On 16 Jun 2017, at 23:18, Quincey Morris >> <quinceymor...@rivergatesoftware.com >> <mailto:quinceymor...@rivergatesoftware.com>> wrote: >> >> On Jun 16, 2017, at 14:41 , Jonathan Mitchell <li...@mugginsoft.com >> <mailto:li...@mugginsoft.com>> 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. 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. Charles _______________________________________________ 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
