Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Charlton Wilbur <email@hidden>
- Date: Tue, 4 Jan 2005 04:02:32 -0500
On Jan 4, 2005, at 3:29 AM, Izidor Jerebic wrote:
On Jan 4, 2005, at 8:37 AM, Charlton Wilbur wrote:
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.
If there is no meaningful semantic representation for writing, don't
write it! Just be sure to then write setValue:forUndefinedKey: to
handle the case where the binding changes. The concept of immutable
object attributes -- those that can be read but not set -- is actually
mentioned in the conceptual documentation for KVC.
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).
You have an odd concept of "impossibly complex."
If your object is KVC compliant for a particular key-value combination,
then before you do something that is likely to change that value, you
call -willChangeValueForKey; then you do whatever it is and call
-didChangeValueForKey:. Sure, you get most of this for free if you use
appropriately named instance variables -- but hey, it's your
implementation: if you have a good reason to do it without instance
variables and handle KVO manually, that's your call to make. You must
be getting *some* benefit from the implementation that makes manual KVO
compliance worthwhile, right? And you must be getting *some* benefit
from KVO in the first place, or you wouldn't be bothering with it,
since nobody is forcing you to use it.
That bears repeating: nobody is *forcing* you to write KVC- and
KVO-compliant code. The point is, though, that if you make your objects
KVC- and KVO-compliant, you get a lot of useful behavior for free,
especially when it comes time ot conect them to a GUI. There's a lot
of space between deciding which keys you'll support KVC and KVO for and
"formulating your object as NSDictionary" -- the former is required for
KVC and KVO compliance, while the latter is entirely hyperbole.
And things shouldn't break if you only bother to keep track of changes
at the object level rather than at the object attribute level, and post
notifications that all the values have changed (whether they have or
not) when the object changes. They won't be as efficient as they might
otherwise be, but again, you must be getting some benefit that makes
that loss of efficiency worthwhile, or you'd change the implementation.
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...
Well, it's a very good solution for some things, and it's not a good
solution at all for other things. Combined with the rest of the object
model and the notification system, it's a very powerful tool indeed.
It is good to know drawbacks as well as advantages of a tool. It makes
for a better choice.
Some of what you claim as drawbacks seem to come from a
misunderstanding of the tool - in particular, this insistence that KVC
places requirements on the implementation of an object (it doesn't - it
just makes it easier to implement if your implementation follows a
particular pattern) and that manual KVO is "impossibly complex" (it
isn't -- but some implementation patterns make it easier to implement
than others). The effort that goes into making objects KVO and KVC
compliant is small compared to the tedious labor of hand-written
controller classes -- but if you don't think so, you're certainly free
to ignore KVC and KVO and write the controller classes by hand.
Charlton
--
Charlton Wilbur
email@hidden
email@hidden
_______________________________________________
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>) |