From: Mark Janssen <dreamingforw...@gmail.com> Sent: Monday, March 18, 2013 4:41 PM
> On Mon, Mar 18, 2013 at 2:51 PM, Andrew Barnert <abarn...@yahoo.com> > wrote: >> Have you even looked at a message-passing language? >> >> A Smalltalk "message" is a selector and a sequence of arguments. > That's what you send around. Newer dynamic-typed message-passing OO and > actor languages are basically the same as Smalltalk. > > Yes, but you have to understand that Alan Kays came with strange ideas > of some future computer-human symbiosis. So his language design and > other similar attempts (like php) is rather skewed from that premise The idea that message passing is fundamentally different from method calling also turned out to be one of those strange ideas, since it only took a couple years to prove that they are theoretically completely isomorphic—and, for that matter, they're both isomorphic to closures. > And also, despite name-dropping, I'm not trying to create anything > like that idea of message-passing. I'm talking about something very > simple, a basic and universal way for objects to communicate. Message passing is a simple, basic, and universal way for objects to communicate. Everything from dot-syntax method calls to JSON RPC protocols can be modeled as passing messages. But what you're talking about isn't message passing. The idea that messages have names, and reference objects as arguments, is fundamental, and by leaving that out, you're talking about something different. In effect, your "objects" are just single-parameter functions, and your "messages" are the call operator. >>> With function or method syntax, you're telling the computer to >>> "execute something", but that is not the right concepts for > OOP. You >>> want the objects to interact with each other and in a high-level >>> language, the syntax should assist with that. >> >> And you have to tell the object _how_ to interact with each other. > > This is a different paradigm that what I'm talking about. In the OOP > of my world, Objects already embody the intelligence of how they are > going to interact with the outside world, because I put them there. The paradigm you're talking about is useless. You have lists that know how to append, but don't know how to get/search/iterate. Almost every useful object needs the intelligence to interact with the world in two or more ways. >> Even with reasonably intelligent animals, you don't just tell two > animals to interact, except in the rare case where you don't care whether > they become friends or dinner. > > You're model of computer programming is very alien to me. So I don't > think it will be productive to try to convince you of what I'm > suggesting, but feel free to continue... My model of (object-oriented) computer programming is that programming objects model objects which have a variety of behaviors, each of which is triggered by sending a different message. This is pretty much the central definition that everyone who programs or theorizes about programming uses. If you read any textbook, wiki page, journal article, or tutorial, they're all talking about that, or something directly isomorphic to it. If that's alien to you, then object-oriented programming is alien to you. -- http://mail.python.org/mailman/listinfo/python-list
