• 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: 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
  • Follow-Ups:
    • Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
      • From: Tim Lucas <email@hidden>
    • Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
      • From: Charlton Wilbur <email@hidden>
References: 
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Philippe Mougin <email@hidden>)
 >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>)

  • Prev by Date: RE: Recommended Books for Obj-c
  • Next by Date: How Do I Flip An NSScrollView?
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread