Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Bob Ippolito <email@hidden>
- Date: Tue, 4 Jan 2005 01:34:42 -0500
On Jan 4, 2005, at 12:40 AM, Philippe Mougin wrote:
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.
Since when is KVC supposed to be a replacement for sending messages?
Did someone say that entire non-trivial programs can or should be
written using only KVC?
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.
Just because Interface Builder doesn't make it ridiculously easy to do
this right now doesn't mean you can't. One way would be to use a
NSValueTransformer that has "a" as an instance variable where each "b"
comes from some array. I don't believe that Interface Builder
currently has an easy way to spell this (though a palette containing
some custom controller(s) might), but that is completely orthogonal to
your claim.
-bob
_______________________________________________
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