Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Philippe Mougin <email@hidden>
- Date: Tue, 4 Jan 2005 06:40:18 +0100
Charlton Wilbur wrote:
> I don't see a qualitative difference between "the result
> of sending this message to the object is this value" and
> "this is the value associated with this key." In other
> words, I don't see that the use of key-value coding is
> inherently incompatible with an object orientation. It's
> just a difference in terminology.
No, because the semantic of object-oriented programming is much more
powerful and versatile than those of Key-Value Coding. Consequently,
KVC cannot support this particular style of programming we call
object-oriented. Sending a message (or invoking a method) is
fundamentally not the same thing than reading or writing the value
associated with a key.
Let's take a very basic and concrete example showing some of the
differences. Using object-oriented programming I can implement a
greaterThan: method on my (hypothetical) Number class. This method will
return a boolean telling whether the receiver is greater than the
argument.
Now I can write, in my code:
[a greaterThan:b]
How do you implement such behavior using KVC? You can't (at least not
in a non-insane way), because the greaterThan: method is not about
reading or writing an attribute. This should hint that, conceptually,
there is more than a terminology difference involved between sending a
message and reading or writing an attribute. You can read or write
attributes by sending messages, of course. But you can also do much
more. And it happens that OOP is precisely about this "more". When you
restrict object-oriented programming to setters and getters, like KVC
does, it is no longer object-oriented programming. Sending a message is
something much more powerful and versatile than accessing an attribute
(And this is probably the very reason Apple choose the KVC approach to
base some functionalities on. Because sometimes, with great power comes
too much generality).
Now, if Cocoa Bindings were implemented on top of an object-oriented
programming model (instead of KVC), you would be able to specify, in
Interface Builder things like: "show in this text field the result of
invoking the greaterThan: method on this object, with that other object
as argument".
I'm not arguing this would be desirable or that KVC is not a good
choice in its areas of use. My point in this thread is just: thinking
that KVC supports object-oriented programming is fooling yourself. It
has nothing to do with OOP. The fact that it is implemented on top of
an object model, and somewhat bridged to it, should not hide the huge
differences between these two programming models.
> But why *can't* objects be the site of higher level behaviors,
> simply because KVC is involved?
They can be. But not in term of their KVC-compliant interface, and
consequently, not when interacting with services built around KVC, like
Cocoa Bindings. Reading and writing attributes (even if you can execute
custom code in your accessors) is not a model of interaction powerful
enough for sites of higher level behaviors (i.e., for objects) in the
general case. This is a fact clearly established, and beaten to death
in the technical literature, including in the reference I gave in my
previous message.
> All that key-value coding offers on top of what was available before
it
> is introspection built into the class library instead of the runtime
--
> introspection which obscures whether the attribute is merely a stored
bit
> of data, a calculated value, the result of a database query, or
something
> altogether different
The kind of things you describe (i.e. implementation hiding) is
available on objects natively. This is even one of the core benefits of
objects. No need to have KVC for that.
Now, if you are talking about how KVC internally uses introspection to
determine if it should call an accessor or directly access instance
variables, or this kind of stuff, this is simply a smart hack to make
easier the implementation of KVC compliant objects by us developers,
not a conceptual advance.
> you're going to have to make a much better case than finding a quote
> from Alan Kay that uses the word "bindings" in a pejorative sense
I thought you liked Kay-Value Coding ;-)
Best,
Philippe Mougin
http://www.fscript.org
_______________________________________________
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