Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Izidor Jerebic <email@hidden>
- Date: Mon, 3 Jan 2005 13:44:16 +0100
On Jan 3, 2005, at 1:01 PM, Tim Lucas wrote:
Izidor,
On 03/01/2005, at 8:16 PM, Izidor Jerebic wrote:
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
This is annoying I agree, but there is help. Check out GandBug at
http://projects.gandreas.com/gandbug/ . Its does runtime debugging of
Cocoa bindings.
OK. Thanks for the URL..
First:
[calculator add:someNumber] ;
Second:
val = [calculator value] ;
newVal = val + someNumber ;
[calculator setValue:newVal] ;
What you've done has completely lost the encapsulation of the 'add'
method to the calculator object.
You can still use [calculator add:someNumber], but inside the 'add'
method you would do:
- (void) add:(float)addition
{
float newValue = [self value] + addition;
[self setValue:newValue forKey:@"value"];
}
Exactly. What I have done in the first example is really wrong. But, as
you can see, it is easier to get bindings working that way. So if you
write bad, un-encapsulated code, it is easier to use bindings. This is
the harm I was talking about.
It takes extra code and effort to push yourself towards both good and
KVC (bindings) code. And if you already have domain objects (in a
framework), it is some work to make them behave as you need them for
KVC.
In all my experience as a developer it was always the truth that good
methods always enabled you to do more with less. Objective-C and Cocoa
are prime examples versus C++ with its bloat reflecting wrong basic
design. Anyhing that requires more work is flawed in some way.
If I need to write extra code for bindings and muck around in IB, and
the result is hard to debug as well, I'd rather write my code without
bindings which is easy to debug, and I have the same functionality and
more control...
I can testify the research staff, teaching staff and students of my
uni (UNSW) have found bindings to be extremely effective and have
never had to sacrifice object modelling to ensure KVC compliance
(except for maybe adding some extra code). Personally I have found
Cocoa bindings to encourage better object designs (for example using a
Window Controller for each window and binding through File's Owner).
That's good.
It seems that I did have too big expectations for bindings - you know:
"no code". They do require KVC and that in turn probably always
requires additional code, especially with existing projects. It's only
a question of cost/benefit analysis then: you choose the path (bindings
or non-bindings) that gets you most benefits, but you will be coding in
both paths.
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