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:01:09 -0500
On Jan 4, 2005, at 12:40 AM, Philippe Mougin wrote:
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.
Reading or writing the value associated with a key, however, *is*
equivalent to sending certain kinds of messages. As a result, I'd
strike the "fundamentally" from your statement, and probably the "not"
as well; if certain types of messages are equivalent to reading or
writing the value associated with a key, then they are at least the
same *kind* of thing. Messages allow for a much more complex
interaction with the object, and so KVC cannot replace message sending
entirely.
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).
But KVC *doesn't* restrict object-oriented programming to getters and
setters. It provides a very handy way to use getters and setters to
connect objects to each other and to trigger actions when things
change. KVC isn't *replacing* object-oriented programming; it's
*augmenting* it, in a way that allows tedious things to be done simply.
It's just syntactic/semantic sugar!
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".
Cocoa Bindings is instead implemented on a subset of an object-oriented
programming model that allows keyed access to object attributes. As a
result, I can't do what you suggest in Interface Builder, but I *can*
create a class that sits between the model class and the interface
class and makes such a thing available, and it will take less code than
doing so without bindings.
The point here is *tradeoffs* -- Apple could have inserted a whole
other object-oriented model in between Objective-C and Interface
Builder, but the cost of doing that was ludicrously high, and you would
have needed to write code in Interface Builder *anyway*. So they
provided a way of getting at a useful subset of the object model -- the
"low-hanging fruit" in marketroid/manager speak -- that allows one to
not write a substantial amount of accessor methods. This is an
enormous benefit. On the other hand, providing KVC and Cocoa Bindings
with a richer vocabulary, so that one could do the sort of thing you
propose, means that there is just as much code for that specification
-- it's just in a text field in Interface Builder rather than in a
View/Controller class in the project in Xcode. This isn't nearly as
beneficial.
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.
I think the fundamental point of disagreement here is that you think
that KVC is some sort of substantial layer, and that people are
thinking it's an adequate replacement for message sending. It's not --
it's just syntactic/semantic sugar that hides some fiddly introspection
work so that certain types of coding (not even programming) work,
common in UI development, are made substantially less tedious. I
wouldn't make the statement, either, that KVC is implemented "on top
of" or "bridged to" an object model -- I'd make the statement that KVC
is *part of* that object model, as an alternate approach to accessors.
> 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.
But again, you're assuming that KVC is intended to somehow replace or
eliminate ordinary message passing, or even (to avoid the intentional
fallacy) that someone might be deluded into thinking that it's a good
replacement for message passing. This is a fact *not* clearly
established. It's not an either-or choice -- KVC is an augmentation,
an alternate form of accessor that's highly useful in some situations.
It *can't* entirely replace the message-based interface to an object --
but it *can* replace accessors.
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