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: Wed, 5 Jan 2005 23:10:42 +0100
Le 4 janv. 05, à 08:01, Charlton Wilbur a écrit :
Messages allow for a much more complex interaction with the object,
and so KVC cannot replace message sending entirely.
Great, we agree on this.
Cocoa Bindings is instead implemented on a subset of an
object-oriented programming model that allows keyed access to object
attributes.
Yes.
And this means that in order to interact with this subset, we have to
design our objects as "things which have attributes".
Here, we are already using the particular conceptual framework of KVC,
since "object attribute" is not a concept that is defined or used by
the OOP theory itself (as opposed as, for instance, the concept of
"object method").
The point here is *tradeoffs*
Absolutely. For some domains, trying to support a general
object-oriented programming model might be impossible, non-optimal or
too hazardous given the current state of the art. I don't know if the
tradeoffs Apple made for Cocoa Bindings are the best ones, and I'm not
discussing this. I'm just answering Izidor's request for comments,
saying that in my opinion he is right thinking that the Cocoa Bindings
technology is (in some sense) not object-oriented.
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.
This is because your original claim:
"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." "
...had me believing you were thinking KVC was an adequate replacement
for message sending. Since in fact we agree it is not, all is well and
we can all enjoy life again!
> 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,
No, no. I'm just stating that the programming model provided by KVC
(and I'm only speaking of KVC alone here) does not support
object-oriented programming, because *conceptually* it deals with some
dictionary-like structures, not with objects and messages.
It's not an either-or choice -- KVC is an augmentation
Well, we were speaking about tradeoffs. Tradeoffs are often about
"either-or choices", don't they?
We should remember what frameworks are about. They use the Hollywood
principle ("don't call us, we will call you") in order to provide a
structure into which we plug our own objects. The way a framework then
interact with our objects can be more or less object-oriented. If the
interaction is based on KVC, it means that the framework requires
objects to support KVC (i.e. to support a dictionary-like semantic and
the corresponding interface) and that the interaction will,
conceptually, not be object-oriented, but key-value oriented.
While KVC in itself can be considered as an augmentation like you said,
when a framework choose (for reasons that can be perfectly valid) to
base its interaction with client objects on KVC only, or on KVC mostly,
it impose restrictions (this is not surprising, most frameworks impose
restrictions or requirements) and a particular conceptual framework.
Each time a new framework in Cocoa is designed around KVC instead of
around a more object-oriented model, Cocoa becomes less object-oriented
(again, this is not necessarily bad; as you said there are tradeoffs to
be made). 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?
The "either-or choice" is present when a framework is being designed
and its designer has to decide if he restricts its interactions with
client objects to KVC only or if he supports a more object-oriented
interaction model. In that sense, sometimes there is actually an
either-or choice.
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