On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote:
I have some quibbles...
On Aug 21, 2008, at 12:54 PM, Erik Buck wrote:
So, in summary, the whole point of KVC is to standardize the way an
object’s properties are accessed regardless of how they are stored.
Well, the real point, to my mind, is to increase the dynamism of
property access. It's to allow properties to be accessed using data
to select the property rather than code. Data that is determined at
runtime or design time (IB).
I agree. "Cocoa Design Patterns" includes an entire chapter about the
"Associative Storage" design pattern, and the whole point of the
pattern is to provide dynamism that allows determination at runtime.
I perhaps over simplified out of a desire to avoid pasting the whole
Associative Storge pattern into the essay.
KVC also provides support (hooks) for change management so that any
change to a property can have application defined side effects like
registering an undo event or validating the change.
Hooks other than the accessors it might invoke? I'm not aware of
that.
In order to make your classes KVC compliant, you must either write the
appropriate accessors or override the valueForKey: and related
methods. The "hooks" in fact are the accessor methods or the
valueForKey: type methods.
KVO
Key Value Observing takes advantage of the change management hooks
provided by Key Value Coding in order to notify other interested
objects whenever an observed property changes.
Again, I don't think KVO takes advantage of existing hooks. It adds
those hooks by generating subclasses dynamically and isa-swizzling.
Unless and until you add a KVO observer to an object, it doesn't
have any hooks.
The hooks are just the accessor methods or KVC compliance methods.
They exist for every KVC compliant class. However, you can use KVO
with a class that is not totally KVC compliant if you call the
appropriate willChangeValueForKey: and didChangeValueForKey: methods.
Obviously it works best with KVC compliant classes. OK - I'll concede
that KVO should only be used with KVC compliant classes. The last
time I described all this in email, I was shot down for even bringing
up the isa-swizzling becaust that's an obscure implementation detail...
KVO is also the basis of “Bindings”. I would go so far as to say
“Bindings” are just a way to specify which objects observe which
properties in which other objects using Interface Builder instead
of writing code to register all those notification observers.
Bindings do more than merely set up KVO observations. The classes
which support bindings also determine what to do when changes are
observed.
That's a detail. The essay was intentionally kept to the main
points. I wanted to focus on the notification aspect because that's
whate the original poster was trying to re-implement.
Although KVO is “built upon KVC”, KVO really only needs change
notifications. So, if you provide the change notifications, KVO
will work even if you don’t really use KVC.
I don't think that's true. KVO relies on KVC. How else can a KVO
change notification include the old or new value? KVO will perform
a KVC query for will/didChange... messages (including the implicit,
automatic invocations of will/didChange... performed in the hooks it
installs).
OK OK - I'll concede that KVO should only be used with KVC compliant
classes.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
