[Python-ideas] Message passing syntax for objects
haoyi.sg at gmail.com
Tue Mar 19 03:14:32 CET 2013
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
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>
> >>> >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
> > 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"
> > "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.
> Python-ideas mailing list
> Python-ideas at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas