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 09:29:24 +0100
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."
In other words, KVC is about the *interface* to your object, not about
its *implementation.* It provides a couple of shortcuts if your
implementation fits a particular pattern, but it works just fine if
your implementation does not.
The problem is most of the time with the 'setXXX' part, which a lot of
times does not have a meaningful semantic representation in the model.
So reading is OK, writing is really problematic, if you want to make it
right.
Second problem is KVO. This becomes imposssibly complex, since you need
to avoid loops and really bend your model implementation around
NSDictionary semantics.
I did have some success with notifications based on changes of complete
object, since this does not force you to formulate your object as
NSDictionary, but anything more granular than that did not work out
(for me in that case, YMMV).
This KVC/KVO really reminds me of the relational database programming
with triggers. Naturally, since it was its first target (EOF).
Generalizing it seems to work for models close to the original (low on
behaviour, rich on data), but further away you go, more problems
arise...
It is good to know drawbacks as well as advantages of a tool. It makes
for a better choice.
And, I fully agree with what the mmalc said (paraphrased): Choose your
own poison.
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>) |