Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Vincent Coetzee <email@hidden>
- Date: Mon, 3 Jan 2005 13:07:42 +0200
Dear List
It is interesting that some developers view Bindings as unnatural.
Being an old Smalltalk and more specifically VisualWorks developer I
find Bindings incredibly natural. One of the basic premises of OO is
that objects pass messages to one another to regulate program flow and
pass values around. This is coded into the Class hierarchy of Smalltalk
with invocations also being known as "messageSends". It follows
therefore that using bindings to link objects and allow them to
broadcast changes and retrieve values is "natural" from an OO
perspective. If one uses MVC as defined within the Pattern community
and it is used in conjunction with the "ValueWrapper" pattern, then
bindings give enormous power. I would concur however that the
documentation associated with Bindings under Cocoa needs to be
drastically improved, and a more gentle introduction needs to be
created by Apple.
Vincent
On Jan 3, 2005, at 11:16 AM, Izidor Jerebic wrote:
Hello!
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
2. Non-obvious
I think that a fairly experienced Cocoa developer should not need to
study manuals to implement Preferences (a couple switches) with
bindings. The GUI in InterfaceBuilder is quite weird, and does not
help you in the least. You need to be the part of inside circle to
understand what you need to type and click to make it work. When it
could be so simple and helping.
This is not a big drawback, but it turned me off the first time I
tried. This could be improved rather easily, though.
3. Procedural thinking - objects as structs
This is the major one, and the most problematic. Cocoa Bindings'
mental model is of objects as passive lumps of data. It shows its
inheritance from EOAssociation and the way it is most correctly used,
but nevertheless, it is quite dangerous, because it forces a developer
to create the application object model in a very non-OO way, if it is
to work nicely with bindings. Bindings are really well suited to
extremely simple objects - a C structs with set/get methods (which
actually are not objects in proper OO sense - those contain behaviour
and data). Anything else makes the developer write additional code to
make objects look like this.
And if a developer is just starting with Cocoa, this non-OO way of
thinking will subconsciously make his object modelling very wrong,
indeed. As an example, lets assume we have a calculator object, which
can perform operations (lets say that calculator holds the operations
as stack, so you can get a paper trail, so nothing as 'value' variable
exists inside of object). There are two ways to implement adding.
First:
[calculator add:someNumber] ;
Second:
val = [calculator value] ;
newVal = val + someNumber ;
[calculator setValue:newVal] ;
IMHO, the first approach is the correct one. But if you want to use
bindings, you will need to write additional code for set/get. The
second one (procedural, not object-oriented) will get you bindings
working for free. No new code. So if you subconsciously learn this,
your code will steadily become procedural and not object-oriented.
In conclusion, I think that bindings are great for preferences (I did
manage to implement them with bindings) and data-oriented parts of
applications (inspectors, data-entry). Bindings will probably become
extremely useful with CoreData, as its predecessors were.
But they are not suitable for general development, and can be really
harmful to proper object-oriented modelling, if applied
indiscriminately...
I would like to be corrected and I really welcome any response that
would do something to point out the mistakes I made in my thinking.
Especially any positive experiences and examples. I do not want to
miss any benefits.
izidor
_______________________________________________
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
___________________________________________________________________________________________________
The views expressed in this email are, unless otherwise stated, those of the author and not those
of the FirstRand Banking Group an Authorised Financial Service Provider or its management.
The information in this e-mail is confidential and is intended solely for the addressee.
Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or
omitted in reliance on this, is prohibited and may be unlawful.
Whilst all reasonable steps are taken to ensure the accuracy and integrity of information and data
transmitted electronically and to preserve the confidentiality thereof, no liability or
responsibility whatsoever is accepted if information or data is, for whatever reason, corrupted
or does not reach its intended destination.
________________________________
_______________________________________________
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