Re: wasting space?
Re: wasting space?
- Subject: Re: wasting space?
- From: "Michael Ash" <email@hidden>
- Date: Sun, 5 Oct 2008 16:13:54 -0400
On Sun, Oct 5, 2008 at 1:05 PM, I. Savant <email@hidden> wrote:
> As to the other 50% of this sentiment, I don't understand the "some of us
> still aren't too convinced about their ultimate utility" comment. By
> "ultimate utility", I take it that you mean some view the Bindings mechanism
> as trivial and not particularly useful. If I'm wrong, please correct, but if
> I'm right, I strongly disagree. Bindings was, by popular belief, of limited
> utility in 10.3 (mostly because of weaknesses/inflexibilities in the
> controller layer with a handful of unsavory work-arounds), but the
> underlying technologies (KVC/KVO) have been a powerful, flexible, modern
> addition to the Cocoa frameworks and continue to grow with each new OS
> release. We'll call 10.4's NSTreeController a ... valiant first-draft. :-)
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." -- Brian W. Kernighan
You are both right and wrong. I don't view them as trivial and not
particularly useful. What I view them as is as *less* useful than the
"old-style" techniques when used for "real work". My experience has
been that, in most non-trivial uses, bindings ultimately cost more
time than they save. This is because, as alluded to in the quote
above, bindings are so clever that they essentially cannot be
debugged. And you *will* have bugs with any non-trivial use.
As an example, I once built an inspection panel with bindings because
it seemed like the best way to go. Lots and lots of text fields, ought
to save a lot of labor over manually setting them up and listening for
changes. And it did, at first, except I kept having to debug it
through, essentially, trial and error, and this took forever. I
*still* have a known unfixed bug in the thing, in that under some
unknown circumstances, one of the fields will display a gray "No
Selection" instead of just being empty when the data for that field is
empty. This sort of bug is, to me, inconceivable in a straight
glue-code approach where all of the workings are exposed for anyone to
see. But my experience with bindings is that this kind of mystery
behavior happens all to often, because there's simply no good way to
find out what's *actually* going on, as opposed to what's supposed to
be.
I realize that a lot of what I'm saying is fairly similar in theme to
arguments used against OO application frameworks in the first place,
and that I may be wrong for the same reasons, but in this case I don't
think so. The difference is that you really *can* see what's going on
under an OO framework once you know how to look. I don't see this
being the case with bindings. I really haven't found any way to
reasonably debug these things besides dumping out the bindings info in
the debugger (always looks like it "should" look anyway), trying to
put breakpoints in KVC accessors, and in general doing a lot of
head-scratching and guessing. If there's a better way to fix these
things when they go wrong I'd love to know what it is.
I agree, mostly, about the underlying technologies. KVC is great. KVO
is terribly, horribly, frighteningly flawed at the API level but it
can still be very handy once you know the Magic Incantation. But
bindings, despite being fairly straightforwardly built on these, just
don't seem to actually achieve their goal of saving me time.
Mike
_______________________________________________
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