• 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: Charlton Wilbur <email@hidden>
  • Date: Wed, 5 Jan 2005 19:41:43 -0500


On Jan 5, 2005, at 5:10 PM, Philippe Mougin wrote:

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?

Well, given that I'm about to demonstrate that message passing and KVC are isomorphic to each other, I think I must disagree with that statement.


Imagine an object-oriented language where there it is only possible to send two types of message. One takes an argument of one object, and can return nothing; another takes no argument, but returns an object. At the same time, the two categories of messages are in different namespaces: an input message and an output message can have the same name. Given these restrictions, can we implement the same sorts of rich object behavior we see in Objective-C and Cocoa?

Well, to start with, whether or not a messages in Objective-C returns something is independent of whether it took an argument or not. So if we have a one-argument message in Objective-C, we can represent it by two messages in the new language -- one to pass in the variable, and one to get the result. They can have the same name, even, for convenience.

In other words, our hypothetical Objective-C line:
	quux = [foo doSomethingWith: bar];

is equivalent, in the new language (which uses C++-like syntax to differentiate it), to:
foo.doSomethingWith (bar);
quux = foo.doSomethingWith;


(Remember that there are only two types of message: they either take one argument and return nothing, or they take no arguments and return something, and the namespaces for those two types of message are separate. This provides a convenient way to implement messages that, in Objective-C, would both take an argument and return a value.) Now, this is arguably clunkier than it would be in Objective-C, but the code is pretty clearly equivalent. It would be extremely difficult to claim that the new language is not object-oriented thus far.

So the next problem is that Objective-C allows us to send messages with *multiple* arguments, and our new language doesn't offer a way of doing that. Well, except that it does - it just needs to be handled explicitly. Suppose our object library has a list object. With that, we can translate:
quux = [foo doSomethingWith: bar andWith: baz];


into this:
	arglist = List.new;
	arglist.append (bar);
	arglist.append (baz);
	foo.doSomethingWithAndWith (arglist);
	quux = foo.doSomethingWithAndWith;

The same code. A wise language designer would probably provide a compiler primitive or macro to create arglists, because otherwise the programmers will do a lot of needless typing. Such a situation might look like this:
foo.doSomethingWithAndWith (@list(bar, baz));
quux = foo.doSomethingWithAndWith;


Idiosyncratic, and probably less convenient for the programmer, but certainly no less object-oriented.

Now, the language designer adds introspection. Instead of sending the messages directly, you can send a message depending on which type of message you wish to send - input or output. So our most recent example could also have been written:
foo.inputMessage("doSomethingWithAndWith", @list(bar, baz));
quux = foo.outputMessage("doSomethingWithAndWith");


which has a striking similarity to:
[foo.setValue: [NSArray arrayWithObjects: bar, baz, nil] forKey: @"doSomethingWithAndWith"];
quux = [foo valueForKey: @"doSomethingWithAndWith"];


which is thus equivalent to:
	quux = [foo doSomethingWith: bar andWith: baz];

Now, the hypothetical new language is not going to be nearly as convenient for the programmer -- in particular, it loses the really nice self-documenting Objective-C method calls, and it turns one fairly clear line of code into two or more lines of less clear code with a lot of repetition. But I think this argument has demonstrated pretty clearly that there's no inherent qualitative difference between objects interacting via KVC and objects interacting via message passing.

So thus I conclude that a version of Cocoa designed entirely around KVC for communication between objects would not necessarily be any less object-oriented than one designed entirely around message passing. My original intuition was right, and the customary use of KVC as an alternate for accessor functions was entirely a red herring.

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:
This email sent to email@hidden


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

  • Prev by Date: Re: Ignore accents when comparing strings
  • Next by Date: Re: Ignore accents when comparing strings
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread