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: Wed, 5 Jan 2005 19:41:43 -0500
On Jan 5, 2005, at 5:10 PM, Philippe Mougin wrote:
For example, consider the extreme situation: imagine a world in which
all and every part of Cocoa would be only using KVC to interact with
our objects. We would be of course free to use object-oriented
programming inside our own code, but Cocoa would only interact with
our objects in terms of "give me the value associated with this key"
and "associate this value with this key". I think we would not
consider Cocoa to be an object-oriented framework, right?
Well, given that I'm about to demonstrate that message passing and KVC
are isomorphic to each other, I think I must disagree with that
statement.
Imagine an object-oriented language where there it is only possible to
send two types of message. One takes an argument of one object, and
can return nothing; another takes no argument, but returns an object.
At the same time, the two categories of messages are in different
namespaces: an input message and an output message can have the same
name. Given these restrictions, can we implement the same sorts of
rich object behavior we see in Objective-C and Cocoa?
Well, to start with, whether or not a messages in Objective-C returns
something is independent of whether it took an argument or not. So if
we have a one-argument message in Objective-C, we can represent it by
two messages in the new language -- one to pass in the variable, and
one to get the result. They can have the same name, even, for
convenience.
In other words, our hypothetical Objective-C line:
quux = [foo doSomethingWith: bar];
is equivalent, in the new language (which uses C++-like syntax to
differentiate it), to:
foo.doSomethingWith (bar);
quux = foo.doSomethingWith;
(Remember that there are only two types of message: they either take
one argument and return nothing, or they take no arguments and return
something, and the namespaces for those two types of message are
separate. This provides a convenient way to implement messages that,
in Objective-C, would both take an argument and return a value.) Now,
this is arguably clunkier than it would be in Objective-C, but the code
is pretty clearly equivalent. It would be extremely difficult to claim
that the new language is not object-oriented thus far.
So the next problem is that Objective-C allows us to send messages with
*multiple* arguments, and our new language doesn't offer a way of doing
that. Well, except that it does - it just needs to be handled
explicitly. Suppose our object library has a list object. With that,
we can translate:
quux = [foo doSomethingWith: bar andWith: baz];
into this:
arglist = List.new;
arglist.append (bar);
arglist.append (baz);
foo.doSomethingWithAndWith (arglist);
quux = foo.doSomethingWithAndWith;
The same code. A wise language designer would probably provide a
compiler primitive or macro to create arglists, because otherwise the
programmers will do a lot of needless typing. Such a situation might
look like this:
foo.doSomethingWithAndWith (@list(bar, baz));
quux = foo.doSomethingWithAndWith;
Idiosyncratic, and probably less convenient for the programmer, but
certainly no less object-oriented.
Now, the language designer adds introspection. Instead of sending the
messages directly, you can send a message depending on which type of
message you wish to send - input or output. 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"];
which is thus equivalent to:
quux = [foo doSomethingWith: bar andWith: baz];
Now, the hypothetical new language is not going to be nearly as
convenient for the programmer -- in particular, it loses the really
nice self-documenting Objective-C method calls, and it turns one fairly
clear line of code into two or more lines of less clear code with a lot
of repetition. But I think this argument has demonstrated pretty
clearly that there's no inherent qualitative difference between objects
interacting via KVC and objects interacting via message passing.
So thus I conclude that a version of Cocoa designed entirely around KVC
for communication between objects would not necessarily be any less
object-oriented than one designed entirely around message passing. My
original intuition was right, and the customary use of KVC as an
alternate for accessor functions was entirely a red herring.
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