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: Fri, 7 Jan 2005 14:21:12 -0500
On Jan 7, 2005, at 1:29 PM, Philippe Mougin wrote:
Well, using your example of result = [a isGreaterThan: b]; as an
example --
Assume that a and b are members of the same class, which has a
private instance variable called 'inputIsGreaterThan' and an accessor
called 'number' that returns an NSNumber:
- (void) setIsGreaterThan: (id) input
{
inputIsGreaterThan = input;
}
- (id) isGreaterThan
{
return [[self number] compare: [inputIsGreaterThan number]] ==
NSOrderedAscending;
}
With this, you can *completely* emulate result = [a isGreaterThan: b]
with KVC calls:
[a setValue: b forKey: @"isGreaterThan"];
result = [a valueForKey: @"isGreaterThan"];
These are not KVC calls.
They have the same signature than KVC calls but the methods they
eventually invoke (i.e. setIsGreaterThan: and isGreaterThan) do not
follow the semantics mandated by KVC, which are to set or get a value
associated with a particular key.
The value the first one sets is the value associated with the key
"isGreaterThan." The second one reads that value. In the interim, the
object does some calculation and alters the value associated with that
key -- but there is nothing in the semantics of KVC that says that the
value you set to be associated with a particular key *must be* the
value you get when you get the value associated with that key, and
there is nothing in the semantics of KVC that says that the object
can't perform some calculations on the value associated with a key, or
alter it internally. (If either restriction were there, then yes, KVC
would be insufficient to emulate arbitrary method calls. But they're
not, and thus it's not.) Out of those semantics, which *are* the ones
that KVC supports, provided you have a large enough set of keys, you
can construct all other method calls.
I think one problem with your argument is that you're strongly focused
on an equivalence between keys and instance variables, and are
interpreting that obvious use as a necessary part of the semantics of
KVC. But there is no such limitation on what a key can be, or the
documented approach to resolving what happens when -setValue:forKey:
and -valueForKey: would restrict itself to naming standards for
instance variables. In particular, there is nothing preventing it from
representing "the list of arguments to a message I wish to send, which
has the same name as the key" when it is set, and "the result of the
message I wish to send, whose arguments have been associated with this
key, and which has the same name as this key" when it is read. In
particular, the mapping of -setValue:forKey: to -set<key>: and
-valueForKey: to -<key>: is a documented part of KVC; this is a pretty
clear indication that invoking code when a key is set or gotten, and
not just setting values in a dictionary, is an intentional part of the
model.
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: | |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>) |