[Python-ideas] Message passing syntax for objects
g.brandl at gmx.net
Mon Mar 18 20:06:33 CET 2013
Am 18.03.2013 05:26, schrieb Mark Janssen:
> Continuing on this thread, there would be a new bunch of behaviors to
> be defined. Since "everything is an object", there can now be a
> standard way to define the *next* common abstraction of "every object
> interacts with other objects".
The problem is that for most objects there isn't *the* interaction. Sure,
you could split up complicated objects into small pieces with a smaller
functionality, but at some point you have to stop. Let's see how this
concept fares with simple types such as integers or collections...
> And going with my suggestion of
> defining >> and << operators, I'm going to explore the concept
>>>> 42 >> MyNumberType #would add the integer to your integer type
That's just random. Why not multiply? Why not exponentiate?
>>>> 42 >> MyCollectionType #would add the object into your collection:
> *poof*: no more random syntaxiis for putting things in collections.\
So you've replaced one method of a collections API by your magical operator,
for all collections. What about the other methods that are just as important,
such as deleting items, indexing, and querying? The "syntaxitis" would stay
just the same, except if you introduce more operators, which means new syntax
Also, how would this work for dictionaries or deques?
>>>> MyObject >> # queries the object to output its state.
What is "its state"? A readable representation? A serialized representation?
A memory dump?
>>>> "http://www.cnn.com" >> MyInternetObject #outputs the HTML text from CNN's home page.
> Each object has to figure out how it will receive things from outside
> of it. Things it can't handle (a string sent to an int) just have to
> be dropped to some other space, much like stderr does within the O.S.
> There are probably many other very interesting examples, but the key
> idea I'm working on (as noted in other messages), is a sort-of
> universal language for the internet, a WebOS to be applied to a
> universal data model.
It seems that you are reinventing pipes (such as UNIX shell pipes).
I agree that as a model for handling data the pipe paradigm is elegant,
but only as long as you deal with simple data of a single kind (such as
strings in the UNIX world). But make the data complex enough, and it's
an instance "all problems look like pipes if all you have is a vertical
More information about the Python-ideas