[Python-ideas] Message passing syntax for objects

[Mark Janssen]

On Mon, Mar 18, 2013 at 7:14 PM, Haoyi Li <haoyi.sg at gmail.com> wrote:
> I felt I just had to chip in here, knowing something about how actors (which
> is basically what you're advocating) work in Scala. Some points:

Thank you.  Your input is valued.

> - Message sends have to give you something that method calls don't

Right.

> Whether that's the ability to ignore not-understood messages (like in
> Obj-C)

That's one.

> , or making the message send-receive behavior asynchronous (like in
> Scala)

That's two.

> or ensuring messages are handled serially per-object,

This happens in either paradigm.

> I think this is a significant point: small things (lists, tuples,
> primitives) are kept as structs and the data inside them is manipulated
> directly,

Yes, and here is where something significant I think will happen.
Complicated data structures just simply don't get re-used.  Python
allows lists within lists within lists, but any program that uses that
outside of n x n matrices won't ever get re-used ever.  Because there
is no unified data model.

> and big things (web servers, background-workers, http clients) are
> then done with state-hiding and encapsulation and all that.

Yeah, that part is fine.

> Having a simple thing (like a list or a tuple) with encapsulation and
> sending messages to it is as silly [...]

Ah, but you see I'm envisioning a data ecosystem (to borrow a phrase)
for the Internet.  A peer-2-peer model for sharing data.  So sending
messages isn't so silly.

> In particular, your dislike for "lists within lists" seems incompatible with
> your desire for "more universal/general classes, building up to the
> complexity desired". Isn't that almost the perfect example of simple,
> general classes used to build up complex structures?

I think I see the source of confusion, I used the word "object" when
that is the term used in Python for lists, etc -- things used to store
data, but I see them as separate.  I make a distinction between
classes which not only may be stateful, but be able to *do* things,
with data types which don't "do" things, but *are* things.  It's a
subtle distinction, rather like languists distinguish between verbs
and object even though both are *words*.

Mark