On Sun, Oct 5, 2008 at 1:05 PM, I. Savant <[EMAIL PROTECTED]> 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 (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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
