Re: How much does NSObject's bind:toObject:withKeyPath:options: do?
Re: How much does NSObject's bind:toObject:withKeyPath:options: do?
- Subject: Re: How much does NSObject's bind:toObject:withKeyPath:options: do?
- From: Matt Neuburg <email@hidden>
- Date: Fri, 22 Sep 2006 07:49:57 -0700
- Thread-topic: How much does NSObject's bind:toObject:withKeyPath:options: do?
On Fri, 22 Sep 2006 16:16:59 +0200, Mailing list subscriptions
<email@hidden> said:
>El 22/09/2006, a las 1:56, R. Matthew Emerson escribió:
>> On Sep 21, 2006, at 12:04 PM, Mailing list subscriptions wrote:
>>
>>> Given that the user may be manipulating the preferences (via
>>> controls bound to the shared NSUserDefaultsController), how do I
>>> know when a synchronize is performed? Does
>>> NSUserDefaultsController perform a synchronize after every single
>>> change? or just periodically? If the latter, then I could find
>>> that I'm getting out of sync with what the user thinks the
>>> preferences are.
>>
>> Take a look at the documentation for NSUserDefaultsController.
>> There's a property called appliesImmediately.
>
>Thanks for drawing that to my attention. The docs are pretty
>unambiguous on that point, which is the way I like it.
>
>>> Isn't this what Cocoa Bindings is for? To keep things in sync
>>> built on top of Key-Value observing, rather than using older
>>> mechanism like notifications and notification centers?
>>
>> Cocoa Bindings doesn't make all other techniques obsolete.
>
>No, but my question is aimed at finding out what the simplest way of
>doing something is, and the most elegant. It seems to me that the
>notification/observer thing is a little bit verbose, and breaks
>encapsulation a little bit (ie. if my controller is going to register
>for specific notifications and then tie itself to specific user
>preferences then it becomes much more implementation-specific and
>less reusable). To preserve encapsulation a bit more neatly I could
>use some other object (the main application controller class, for
>example) to register for those notifications and relay important
>changes to the other controller, but then I am back in the land of
>glue code again. And yet another alternative (the way I actually did
>it on the first try) is to use Cococa Bindings in the main controller
>to be notified of changes to the prefs and again relay the changes to
>the other controller. This is cleaner than using notifications
>because the notifications don't tell me what changed (so I have to
>figure out what changed and whether or not to notify the other
>controller) whereas with Bindings I know exactly what changed and
>there's less code to write...
>
>But my curiosity about the workings of
>bind:toObject:withKeyPath:options: still remains... how much does the
>default implementation in NSObject actually do, and does it do enough
>that you can rely on it to set up simple bindings where you want the
>instance variable of some other class to change whenever an
>observable controller notes a change in a model or a view somewhere?
>And if it handles the simple case, what are the limits? Will value
>transformers be handle automatically? Or do you get nothing "for
>free" and you really have to subclass
>bind:toObject:withKeyPath:options:?
There are two aspects to this question - theoretical and practical.
(1) From a theoretical (perhaps I should say "religious") point of view,
this matter has been argued from here to the back of beyond on this list,
and you can easily peruse the archives (at cocoabuilder.com) to study the
entire sordid history.
(2) From a practical point of view, if you want to use bind:... for
something and you want to know how your app will behave, why not try it and
find out?
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden