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 02:37:41 -0500
On Jan 4, 2005, at 2:14 AM, Izidor Jerebic wrote:
What if there is no 'value' instance variable ?
There doesn't need to be. KVC works just fine if there's a method
called 'value' that takes no arguments.
This example and various arguments clearly shows the problems -
everybody immediately assumed that there must be an instance variable
'value'. This is implementation detail and nobody can assume what the
implementation is, based on the object interface.
But KVC is not about implementation, it is about interface. In cases
where there's an instance variable, you can get at that with KVC
methods. In cases where there isn't (or in cases where you want
accessors anyway), you can write a -value method and a -setValue:
method to support the "value" key -- or if you want to support reading
that value or writing to that value, you can implement one method or
the other.
A good deal of the time with KVC there will be an instance variable.
It's a reasonable default assumption.
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.
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>) |