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 13:31:44 -0500
On Jan 4, 2005, at 5:28 AM, Izidor Jerebic wrote:
Well, let's say the KVC puts some pressure on you and directs you
towards certain implementation patterns and away from others. This has
nothing to do with how well suited are those patterns for your domain
objects, but only has to do with how easy is to implement KVC/KVO.
I wouldn't say that KVC offers any "pressure" at all. I'd say that KVC
and KVO offer a different set of tradeoffs -- it's the benefits you get
from those tradeoffs that determine whether you should change your
implementation patterns or not. If you get enough benefits from the
implementation patterns that make KVO more difficult (and we *are*
talking about "more difficult" involving perhaps two hours' thought and
perhaps two dozen lines of code!) to make it worthwhile using them, you
should. If you aren't getting enough benefit to make it worthwhile,
then you probably ought to change them.
and that manual KVO is "impossibly complex" (it isn't -- but some
implementation patterns make it easier to implement than others).
Again, after the object model is built according to domain
requirements, it is substantial work to have it support KVO, if it
does not fit already.
Once again, you seem to have a different meaning of "substantial work"
than I do.
For KVC: You select the keys your object needs to support. Odds are
that these are already methods, if they're information useful to things
interacting with the object; all you do is rename them or wrap them in
another method to fit the name of the key you've selected. You
implement two methods to be called when something attempts to read or
write a key that doesn't exist or shouldn't be written, as a safety
net. (You can ignore these if you want; the default implementation
logs a complaint on the console, and that's adequate warning in some
cases.) The additional work here is *at most* writing two simple
methods per key (since most likely the information is already
available), plus possibly the two default methods.
For KVO: every time you are about to change the values associated with
a key, you send the -willChangeValueForKey: method. After you have
changed it, you send the -didChangeValueForKey: message. If you don't
want to handle things at the resolution of a single key -- perhaps your
keys are all interdependent, and there's a good chance that changing
the inputs will result in them all changing -- you can wrap this in two
methods that send the -didChangeValueForKey: message for all keys and
the -willChangeValueForKey: message for all keys.
What we're talking about here is, in the worst case, *maybe* two to
three hours worth of coding that's pretty mindless and straightforward
once the interface is already designed. None of it depends on the
implementation. If that's what you consider "substantial work," well,
I've already spent more time on this thread than it would probably take
me to make even a complicated object minimally KVC and KVO compliant.
So I do not claim that there are some immovable requirements for
KVC/KVO. I am just stating that KVC/KVO interferes with your design
choices,
Except that it doesn't! It changes the tradeoffs, which means that
choosing a different implementation behavior might save you work in the
long run, but you can implement KVC and KVO no matter what the
implementation of your object looks like.
and that it may be bad for some situations, notably those that have
complex object behaviour (note that those are the ones I consider real
OO designs - the rest is just relational scheme of data, no
behaviour).
As there are no situations in which KVC or KVO restrict your object
behavior or your design choices, I have a hard time accepting your
claim that it may be *bad*. At the absolute worst it may require
around 3 hours of work that doesn't turn out to offer any benefit --
and if you suspect that that may be the case, you can defer the 3 hours
of work until you expect to see the benefit.
KVC and KVO do not have *any* *impact* *whatsoever* on complex object
behavior. They just offer an alternative approach to accessors (which
you'd need to write anyway!) and automatic notification when the values
associated with an object's keys change. If you don't find either of
those useful, don't use them -- but please don't keep on claiming in
the face of the evidence that they impose arduous requirements on the
implementation of a class, that they prevent or inhibit complex object
behavior, or that they're difficult to implement.
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>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |