[Python-ideas] Message passing syntax for objects
dreamingforward at gmail.com
Wed Mar 20 05:36:16 CET 2013
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
> Whether that's the ability to ignore not-understood messages (like in
> , or making the message send-receive behavior asynchronous (like in
> 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
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*.
More information about the Python-ideas