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: Thu, 6 Jan 2005 13:45:09 -0500
On Jan 6, 2005, at 11:56 AM, Philippe Mougin wrote:
There is a flaw in you demonstration when you state that:
So our most recent example could also have been written:
foo.inputMessage("doSomethingWithAndWith", @list(bar, baz));
quux = foo.outputMessage("doSomethingWithAndWith");
which has a striking similarity to:
[foo.setValue: [NSArray arrayWithObjects: bar, baz, nil] forKey:
@"doSomethingWithAndWith"];
quux = [foo valueForKey: @"doSomethingWithAndWith"];
...and conclude that your language and KVC are equivalent.
The "striking similarity" you see is only at the very superficial
level of methods signatures. But you left out completely the semantics
of KVC, which are defined by the KVC documentation and attach to the
setValue:forKey: and valueForKey: methods a particular behavior.
Unfortunately, the semantics provided (or mandated) by KVC cannot
support the semantic of the language you describe, and consequently
your language cannot be considered as something equivalent to KVC.
Why can't KVC support those semantics? I've demonstrated that any
complex message can be composed of two types of messages that meet
certain restrictions, and I've demonstrated that those two types of
message are equivalent to -setValue:forKey: and -valueForKey:. It
logically follows that KVC is isomorphic to message passing; choosing
one or the other does not restrict the behavior available to objects at
all. You can argue that the *intent* of KVC is not to replace message
passing, and you'd probably be right; you can argue that KVC as
implemented in Cocoa is a subset of its full power, and you'd be right;
you can even argue that using KVC instead of message passing would be a
major chore for programmers, and you'd definitely be right. But your
argument is that KVC *cannot* support the semantics necessary for real
object orientation. If that's true, since KVC is isomorphic to message
passing, then message passing can't support the semantics necessary for
real object orientation either. I believe this is called "proof by
contradiction"; if you want to disprove it, you have to find a flaw in
the demonstration that KVC is isomorphic to message passing.
For instance, the semantic of -(void)setValue:(id)value
forKey:(NSString *)key in KVC is (short version): "Sets the property
of the receiver specified by key to value".
This semantic is way too precise and narrow to support the semantic of
messaging in general which, depending on the message that is sent, can
be absolutely anything.
You are hung up on the word "property," which in this case is
completely irrelevant.
Step 1 in the demonstration is to show that all messages can be
decomposed into a combination of input messages, that take one argument
and return no value, and output messages, that take no arguments and
return a value.
Step 2 in the demonstration is to show that our input message is
equivalent to -setValue:forKey: (which can be equivalent to -(void)
set<key> with the value as an argument), and that our output message is
equivalent to -valueForKey: (which can be equivalent to -<key>, which
is expected to return a value).
If all messages can be decomposed into a sequence of messages with
constrained signatures, and each type of message with constrained
signature is equivalent to a KVC message, then all messages can be
decomposed into a sequence of KVC methods. Thus you cannot claim that
it is impossible to support more general behavior using KVC unless you
are also prepared to claim that it is impossible to support more
general behavior using message passing, because (as demonstrated!)
anything you can support using message passing, you can also support
using KVC.
The semantic of KVC (which is its "raison d'etre") is about setting
and getting the values of the properties of an object. Given such
semantics it is impossible to support the more general behavior of
"invoking an arbitrary method that can do whatever it wants".
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"];
You're welcome to argue that result = [a isGreaterThan: b] is not
"invoking an arbitrary method to do whatever it wants," but at this
point it should be obvious that any complex message can be decomposed
into some combination of -setValue:forKey and -valueForKey: calls.
Doing so with any message more complicated than that -isGreaterThan is
likely to be lengthy, which is certainly an argument that message
passing is more *convenient*, but again that's not the argument you're
making.
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>) |