Re: The problem with bindings
Re: The problem with bindings
- Subject: Re: The problem with bindings
- From: Brent Gulanowski <email@hidden>
- Date: Fri, 30 Jul 2004 17:42:04 -0400
On Thu, 29 Jul 2004 22:42:19 -0700, mmalcolm crawford
<email@hidden> wrote:
>
>
On Jul 29, 2004, at 3:50 PM, Brent Gulanowski wrote:
>
>
> I think KVO is by far the most obscure and difficult to adapt one's
>
> thinking
>
> to. This I think correlates with the fact that KVO does the most
>
> behind-the-scenes manipulation.
>
>
>
Could you explain in greater detail your difficulty?
>
(This is written in the spirit of investigation, not deprecation.)
>
>
The basic aim of KVO is simple:
[snip]
You are right, of course. As I'm using it, even just today, the
unfamiliarity is quickly fading and it's already difficult to
articulate it in more detail. Maybe it's hard to believe it's so
simple? Ach, in retrospect it's hard not to feel foolish.
It may just be an overdeveloped sense of distrust when one first meets
a new pattern.
>
In many respects it's conceptually a specialised case of standard
>
NSNotifications, with which people typically don't seem to have much
>
difficulty. A main difference(**) is that, whereas with traditional
>
notifications you get to specify the method that gets called when a
>
notification is posted, everything is channeled through a single
>
method. That is one reason why you typically provide a context object
>
-- it helps you to identify why you're getting a change notification.
>
>
(*) observeValueForKeyPath:ofObject:change:context:
>
>
(**) From the "consumer" perspective; from the implementation
>
perspective clearly there's another major difference in that change
>
notifications are sent directly without requiring a notification
>
centre.
Well my initial ideas about how the notification center worked were
themselves overblown. Just this silly suspicion that things were going
on that were somehow "special" or secret, when it was just one level
of indirection.
>
> I think that we need more KVO examples without bindings. I'd be
>
> interested to see what applications of KVO are possible without
>
> bindings, or if KVO was really just a solution to a problem in
>
> bindings (in which case, maybe there is a less obscure solution?).
>
>
>
Aaron gives a good example of using KVO to support undo management (see
>
Chapter 7 of "Cocoa Programming for Mac OS X"), I'm sure there will be
>
others.
A good reason to pick it up, although having the first already I'm
reticent -- lack of bookshelf space! I guess I can give away my old
copy.
>
> Still, the NSObjectController and NSArrayController classes tend to
>
> work best in specific types of environments, and the amount of genius
>
> required to adapt them to atypical situations seems to be exponential
>
> to the atypical-ness. They are really hard to subclass, I find.
>
>
>
In what sense hard to subclass? There are a couple of clear "choke
>
points" for subclasses -- newObject to customise the creation of a new
>
object, and arrangeObjects: for sorting/filtering. You might also add
>
logic or variables to support other behaviours. There are a couple of
>
examples at:
>
<http://homepage.mac.com/mmalc/CocoaExamples/controllers.html>
>
(notably the last three or so).
Thanks for all of those, by the way -- I have indeed checked them all
out to greater or lesser degrees. I missed the -newObject method,
which I can't explain. Perhaps some more blinking lights and arrows
for the dense in the documentation...
I would hazard a guess to say that it is more difficult to pick up on
an object pattern in a couple of cases:
1. when multiple classes are involved, especially when they are
unlikely to be used individually (i.e.: controllers)
2. when a new protocol/category is involved on NSObject, especially if
it, again, only has any value when the relationship between two
objects is considered. i.e.: an observed object is nothing without an
observer.
Bindings themselves are just a challenge because they are a bulk
package of new technologies. As I mentioned to Scott, part of the
initial confusion for bindings is the sense that KVC and KVO take care
of themselves, which is true up until you want to customize. So the
documentation and examples ought to in some way emphasize the (granted
obvious in retrospect) fact that KVC and especially KVO are important
in their own right. But you know, we trick ourselves since we want to
get to the good stuff, and this may be only my experience.
>
> The extent to which one is asked to trust in the frameworks is much
>
> higher, which is disconcerting at first (OK, still is).
>
>
>
That's a common experience. Unfortunately there's probably little that
>
can be done about that -- since of course the goal is to provide as
>
much built-in functionality as possible... you'll have to trust it to
>
get it!
>
>
> Well at first I was perplexed by the exceptions until I noticed that
>
> the Run log was spitting out the problem with my use of incorrect
>
> keys.
>
>
>
These errors probably account for a significant percentage of problems.
>
Getting into the habit of reading the error messages is a good
>
thing...
Well true enough. But what about catching the generated exceptions? Is
this recommended over simply crashing and reading the error log?
>
>
> I have been left confused by behaviours that simply don't make
>
> sense to me, based on what I would have expected. Again, this is when
>
> trying to subclass.
>
>
>
.... that said, the greater degree of abstraction afforded by bindings
>
can certainly make tracking down problems more difficult in more
>
complex situations. As with many other things, it's a trade-off...
>
>
mmalc
>
--
Brent Gulanowski
http://www.boredastronaut.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.