• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>)

  • Prev by Date: Re: [Moderator] EOT: OT request: Shareware anti-cracking - need info
  • Next by Date: Re: 2 problems.
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread