Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Mark Munz <email@hidden>
- Date: Mon, 3 Jan 2005 09:58:08 -0600
On Jan 3, 2005, at 3:16 AM, Izidor Jerebic wrote:
I tried really hard to incorporate bindings in my new application.
Really.
But somehow I couldn't do it. I could not point my finger to the
reason, but it just didn't feel right.
Now that I read Scott Stevenson's remark, that "most developers still
insist on using datasource methods" or something like that, I did some
thinking and came with these reasons why I could not use bindings.
First two are practical, the last and most important is a principled
one:
1. Non-debuggable
Once you use bindings, and program does not behave as it should, you
can only slaughter chicken or goats and dance and pray to the
all-mighty god of Cocoa to help you. There is no tool to help you see
what is and is not happening. This is a major drawback
I agree 100%. Users expect magic (things just work the way the expected
it to), but programmers need to be able to step through each piece to
insure the results are expected (and that the unexpected is dealt
with). I get the whole KVC, KVO concept. That's not what bugs me with
bindings. It's the magic, in particular with NSArrayController that
I've struggled with.
In my opinion, the fact that basic operations like Drag-n-Drop still
require "glue code" defeats the purpose of a general purpose array
controller. If I have NSObjects that support the copy-protocol,
Drag-n-Drop should be free. I think it adds to the confusion -- well,
the data is automatically handled for you via magic in the
NSArrayController unless you're doing a drag-n-drop, then you have to
perform the magic (great, but what happens when you don't understand
what the magic is because it not well documented).
I don't think NSArrayController is a bad idea (far from it), but the
implementation and vague documentation (I've seen every sample I could
get my hands on -- including Malcolm's, Apple's docs, updated books,
etc) make it much harder to learn/use. There is no way to tell what is
happening with the NSArrayController objects. I can get stuff to work,
but I don't understand why the stuff I got to work does what it does.
It's very click-and-pray. I've would love to see an example of
NSArrayController with just one basic type -- NSStrings. Essentially,
an example of a basic List. Start off without drag-n-drop support. Then
add it. Do I need to encapsulate my NSStrings in another object or can
I use them directly (I don't believe I've seen an example of them used
directly)?
There is also a general flaw with using Interface Builder to develop
applications -- there are no diagnostic tools that easily show
connections (Outlets and Actions and Bindings) for each object. You
essentially have to click on each object and view the connections,
bindings individually.
I will download this debug tool mentioned by someone else in hopes that
it will help. I believe there definitely needs to be support built-into
Cocoa to make debugging with the use of bindings easier. In my opinion,
click-and-pray is not the way to develop code.
Finally FWIW, if the intent is to reduce code, I think there should be
a way to support basic properties without having to write the glue code
to access each one property.
And yes, I will write up some this via bugs in RADAR to Apple, but that
often times results in it just being called a duplicate because the
needs/wants are fairly obvious.
Mark Munz
_______________________________________________
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