Re: KVO and the observeValueForKeyPath bottleneck
Re: KVO and the observeValueForKeyPath bottleneck
- Subject: Re: KVO and the observeValueForKeyPath bottleneck
- From: Matt Neuburg <email@hidden>
- Date: Thu, 20 Jul 2006 18:57:13 -0700
- Thread-topic: KVO and the observeValueForKeyPath bottleneck
On Thu, 20 Jul 2006 16:14:51 -0400, Scott Anguish <email@hidden> said:
>
>On Jul 20, 2006, at 3:25 PM, George Orthwein wrote:
>
>> I don't think implementing "one way" or "read only" bindings is a
>> misuse, though it almost seems that way since there aren't any
>> examples or mentions of it in the docs that I remember seeing. I
>> think I'll file a doc request.
>
> binding between model objects isn't recommended at all. the bindings
>doc is clear about how we recommend doing it (controller to model,
>view to controller.. it would be useful to extend that to the
>occasional view to model as well though, I'll add it to the list).
However, those terms don't carry all that much meaning in real life. They
are useful as conceptual notions of the role a class is to play in the app,
but what exactly each of those things *is* becomes very muddy in actual
practice.
For example, I'm using bind: to cause my main app controller, MyObject, to
have its "paths" ivar synced with a "paths" value supplied (thru manual KVO)
by a matrix subclass, MyMatrix. Would you try to claim that this is wrong?
Why? On the grounds that MyMatrix isn't a view? (It's a NSMatrix! It's
sitting right in a window!!) Would you try to claim that MyObject isn't a
controller? (Its job is exactly to coordinate the mediation between data and
interface; if that isn't a controller, what is?) And yet formally there
isn't the slightest difference between this and using bind: to cause an
arbitrary ClassA to observe an ivar in an arbitrary ClassB.
Or, let's look it another way: as I pointed out in an earlier thread, when
you say bind: to bind MyObject to the NSUserDefaultsController, nothing
special happens; NSUserDefaultsController isn't any more bind-savvy than
MyObject, and the binding is still one-way only (it's just the observing
part, in one direction). Yet NSUserDefaultController is an NSController
subclass and has "controller" in its name. In fact, I've even done a
double-bind, binding from MyObject to NSUserDefaultController, and from
NSUserDefaultController's "values" back to MyObject, using the same key, to
create a true two-way binding so that the keys are in constant sync in both,
and nothing bad has happened. In fact, what happened is good! It's a
binding!
So it seems to me wrong on the facts and wrong on the law to say you can't
use bind: like this. It's wrong on the facts because it works great, whereas
the addObserver: / observeKeyValue... thing (as posters on this thread and
others have already pointed out) doesn't work particularly well. It's wrong
on the law because it is plainly *meant* to work, creating a nice
automatically maintained pairing between a key in one object and a key in
another object, whereas the addObserver: / observeKeyValue... thing is an
architectural nightmare for your code.
(Anyway, you don't say not to use the addObserver: / observeKeyValue...
thing between two model objects. Yet I fail to see the difference between
this and bind: - the effect is just the same, except that bind: works
better.)
In short, I have come to see the warning against bind: as a kind of canard;
it is a cute but purely theoretical grumble. In actual practice, I am now
using bind: like crazy and my code has been wonderfully streamlined. Once
we're past awakeFromNib, where all the bind: commands are given (wherever a
binding could not be set up in the nib, of course), MyObject becomes
self-contained; it finds within its own ivars all the values of all the bits
of the interface, and it can change any of those bits by setting one of
those ivars. No outlets to the view, no consultation of the view as if it
contained data (i.e. as if it were a model). Isn't that exactly what
bindings are for??? 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