On Jan 3, 2005, at 8:48 PM, Philippe Mougin wrote:
It doesn't come from Bindings themselves but instead from Key-Value
Coding. Actually, everything that is based on KVC (more and more
things are) become largely de-objectified. This is not surprising,
since KVC introduces a non-object-oriented programming model. In this
model, instead of sending messages to objects, we associate values
with keys.
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, honestly: I'm not going to
announce that C++ is not object-oriented because it refers to
subprograms associated with an object as "methods" rather than
"messages." Neither am I going to announce that Cocoa with KVC is not
object-oriented because, instead of sending a setter message with an
argument or sending a getter message, one sets a key to a value or one
gets the value associated with the key. You are certainly free to
treat objects as "mere structs" once KVC is in use, but nothing
whatsoever requires you to do so.
Of course, since Cocoa was originally heavily object oriented,
technically we still use objects when using KVC. This is why we still
see objects, object controllers, method invocations everywhere.
However, conceptually, we don't use them as objects, but as
dictionaries, or, as you put it, mere structs, with the nuance that,
by implementing accessors, we can still execute custom code when a
field of the struct is read or written. A bitter consolation if, like
Alan kay, you think that "objects should be presented as site of
higher level behaviors" and that "[with objects] you can now replace
bindings and assignment with goals" (cf. "The early history of
Smalltalk", Allan Kay, Apple Computer).
But why *can't* objects be the site of higher level behaviors, simply
because KVC is involved? 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 -- and a
standard way of notifying those objects that have expressed an interest
when one of the public attributes of a class changes.
In other words, instead of saying [object foo] and [object setFoo: bar]
I can *also* say [object valueForKey: @"foo"] and [object setValue: bar
forKey: @"foo"]. Making that level of introspection available, making
it automatic, and tying it into the notification system enables a lot
of powerful behavior, but if you're going to support the claim that it
inherently makes things *less* object-oriented, 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.
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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
