[Python-ideas] Message passing syntax for objects

[Haoyi Li]

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:

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

Whether that's the ability to ignore not-understood messages (like in
Obj-C), or making the message send-receive behavior asynchronous (like in
Scala) or ensuring messages are handled serially per-object, it has to be
something. Message sends which don't provide anything over method calls are
really just method calls with a funky syntax.

As such, in Scala actors are used when you need these benefits: stateful,
mutable objects which are accessed from multiple threads but have
non-thread-safe innards, or objects whose allowed behavior changes over
time and the "ignore not-understood messages" thing comes in handy.

Worker/connection pools, state-machines, that sort of thing. Nobody sends
messages to integers or lists!

- Actors (or message-based objects) work in tandem with case classes
(data-based objects/structs) and don't replace them.

I think this is a significant point: small things (lists, tuples,
primitives) are kept as structs and the data inside them is manipulated
directly, and big things (web servers, background-workers, http clients)
are then done with state-hiding and encapsulation and all that.

Having a simple thing (like a list or a tuple) with encapsulation and
sending messages to it is as silly as having a massive structure with all
its internal structures and data exposed to the outside world.

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?


That's all for now
-Haoyi





On Mon, Mar 18, 2013 at 9:38 PM, Mark Janssen <dreamingforward at gmail.com>wrote:

> On Mon, Mar 18, 2013 at 5:39 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
> >>> >So you've replaced one method of a collections API by your magical
> >>> > operator,
> >>> >for all collections.
> >>
> >> Yes -- for all collections.  That's a pretty big gain right?
> >
> > No, not at all. If it's a gain at all, it's a tiny, microscopic gain. But
> > it's not a gain. We lose a lot:
> >
> > - we can no longer distinguish between *adding* something to an unordered
> > collection, and *appending* to an ordered collection;
>
> Your ClassName or __doc__ is supposed to make that clear, because your
> API doesn't.  This is the problem I'm referring to when I talk about
> "hyper-personal API's" -- you have to learn the programmer's personal
> language.  Even 15 years of python append and extend are still
> ambiguous and confusing.  You've adapted to this.
>
> > - we can no longer distinguish between (for example) *appending* to the
> end
> > of a list, *extending* a list with a sequence, and *inserting* somewhere
> > inside a list.
>
> Well, these are old data paradigm operations which will go away in my
> view.  The very thinking in terms of "lists within lists" is very
> personal and no one else will be able to use whatever you're building.
>
> > - we cannot even distinguish between "put this thing in your collection"
> and
> > "search your collection for this thing", since we're limited to a single
> >>
> > "send message" operator.
>
> Ummm, perhaps you missed something in Python: "search your collection
> for this thing" is done with "in"; i.e. , "item in myObject".  That
> already is TOWTDI way to do it.  Obviously, the first item is already
> handled with the messaging operator.
>
> > E.g. what syntax would you use for something like this? [...]
>
> Keeping in mind, this idea would require a major refactoring of the
> standard library.  Instead of these very ornate (byzantine?) complex
> classes, we have many smaller, more universal/general classes,
> building up to the complexity desired (like Unix pipes did for shell
> scripting, files, and the O.S.).  Those "universals" haven't been
> conceived yet for Python, so I don't know yet what it will look like.
>
> > * Open a file with that name.
>
> Why does everyone seem to pick the most corner-type cases?  As this is
> about a "universal data model", issues with interacting within the
> existing operating system becomes an issue and has to be specially
> handled.  So you have to ask how deep you want me to go in this
> architectural model I'm envisioning, because as it is a universal
> model, ultimately the O.S. changes radically (which is why I was
> suggesting that the issue of Python async behavior be postponed).
>
> But now that you have me thinking on it, I see the file system as
> being composed of namespaces organized in a tree.  The Python
> interpreter would access them directly.
>
> Mark
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130318/39baf181/attachment.html>