Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #41390 > unrolled thread

Message passing syntax for objects

Back to article view | Back to comp.lang.python

Contents

  Message passing syntax for objects Mark Janssen <dreamingforward@gmail.com> - 2013-03-17 20:53 -0700
    Re: Message passing syntax for objects Tim Harig <usernet@ilthio.net> - 2013-03-18 07:06 +0000

#41390 — Message passing syntax for objects

Hello,

I just posted an answers on quora.com about OOP (http://qr.ae/TM1Vb)
and wanted to engage the python community on the subject.

Alan Kay's idea of message-passing in Smalltalk are interesting, and
like the questioner says, never took off.  My answer was that Alan
Kay's abstraction of "Everything is an object" fails because you can't
have message-passing, an I/O task, working in the same space as your
objects -- they are two very different functionalities and they have
to be preserved **for the programmer**.

This functional separation made me think that Python could benefit
from a syntactical, language-given separation between Classes and the
messages between them, to encourage loosely-coupled, modular OOP.
Something that OOP has always promised but never delivered.

I think we should co-opt C++'s poorly used >> and << I/O operators
(for files) and re-purpose them for objects/classes.  One could then
have within interpreter space, the ability to pass in a message to an
object.

>>>  42 >> MyObject  #sends 42 as a message into MyObject

The Object definition would then have special methods __in__ to
receive data and a special way of outputing data that can be caught
__str__(?).

I'm hoping the community can comment on the matter....

Thanks,

Mark
Tacoma, Washington

[toc] | [next] | [standalone]

#41399

On 2013-03-18, Mark Janssen <dreamingforward@gmail.com> wrote:
> Alan Kay's idea of message-passing in Smalltalk are interesting, and
> like the questioner says, never took off.  My answer was that Alan
> Kay's abstraction of "Everything is an object" fails because you can't
> have message-passing, an I/O task, working in the same space as your
> objects -- they are two very different functionalities and they have
> to be preserved **for the programmer**.

Without concurrency, message passing and interacting through functions
are semantically similar.  You have operating for sending and receiving
messages.  Python does this through methods which potentially have inputs
and outputs.  Function syntax does have two slight advantages over pure
message passing.

1. A command is sent with the message as opposed to requiring requests to
	be parsed from the message separately from the data.

2. Functions constrain what actions are available and what inputs they can
	legal accept.  This is doubly true

With concurrency, CSP has shown us that message passing is valuable for
syncronization.  Most CSP languages retain the idea of passing messages.
This need not be the case.  The same semantics could be acheived through
function call syntax, although it would likely be less intuitive.

If you want to pursue your ideas further, and you have not already,
I suggest that you investigate Erlang and its CSP based "concurrent
oriented programming."  Alan Kay, himself, commented that he felt it
matched his ideas of message based OOP.  When you return, there is a
"Candygram" package providing similar constructs (last I knew, it did not
yet impliment light weight processes) for Python.

You might also look at using Go which has CSP based channel and coroutine
semantics.  It has many things in common with Python.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web