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: Tue, 4 Jan 2005 10:07:09 +0100
On Jan 4, 2005, at 9:29 AM, Izidor Jerebic wrote:
On Jan 4, 2005, at 8:37 AM, Charlton Wilbur wrote:
If I want to make this object KVC/KVO compliant, there is
substantial work to be done. And not because the object is badly
designed. I can change its implementation any time. This means its
design is OK. KVC/KVO is influencing its implementation, not design.
KVC says, roughly, that if you try to read a key called "foo" that it
looks (in some order) for an instance variable called foo or _foo or
a method called foo. In your example, you might have a reason not to
store the value -- that's fine. You can make it KVC compliant by
providing a method that takes no arguments, with its name the same as
they key you are using. If you only want to be able to read one
value from it, that's one method that you need to implement -- hardly
"substantial work."
One additional important point that I forgot in my previous email: this
is the Model we are changing, and the reason for changes is the View.
So we are putting the view-related stuff into the model. This bothers
me a lot.
If your model is already KVC/KVO like (with getters/setters), bindings
are a great way to put your model into view. If not, there is a
question: how much additional view-related stuff you can tolerate in
the model and how much work the bindings do for you. It's up to you to
calculate (heh) the costs/benefits.
EOF did not have these problems, because in EOF there was a way of
having all your logic in a category (separate file), using the
accessors. But with EOF the design usually started with the relational
scheme, and object classes were generated from it. Just the reverse of
OO design, where you specify goals, and then proceed from goals
(external interface) to internal implementation.
I must say this discussion is really fruitful (to me, YMMV :-).
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
| References: | |
| | >Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Tim Lucas <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |