[Python-ideas] Message passing syntax for objects

Mark Janssen dreamingforward at gmail.com
Mon Mar 18 21:24:49 CET 2013


On Mon, Mar 18, 2013 at 12:06 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> 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.

Yes.  But that is the point, if you look at the quora post -- to
invert the object model and create mashups of simple modular data
types and working *upwards*.

>  Let's see how this
> concept fares with simple types such as integers or collections...
>
>>>>> 42 >> MyNumberType #would add the integer to your integer type
>
> That's just random.  Why not multiply?  Why not exponentiate?

Well, as I noted in another post, that while these can be broken down
into their simpler component (addition and negative numbers), numbers
should probably be treated separately.

>>>>> 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.

Yes -- for all collections.  That's a pretty big gain right?

> 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
> again.
>
> Also, how would this work for dictionaries or deques?

Well, now you get into the Work:  a unified data model.   Deques,
trees, lists, etc were all preliminary evolutionary explorations on
this giant computer science journey of knowledge (and data types)
which will have to be, can be, pruned and dropped.

>>>>> MyObject >>     # queries the object to output its state.
>
> What is "its state"?  A readable representation?  A serialized representation?
> A memory dump?

That's still for us to decide.  We're mastering the OOP paradigm here:
  What is the ideal object and what is "in common" across all objects?
  We are Zen, we want to master the notion of object.  What is the
simplest object model possible without sacrificing critical
functionality...

>>>>> "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).

That is a very interesting comparison.  That is something like what
I'm trying to do.  In tandem with the Internet, I do see a kind of
synthesis of Web + O.S. integration -- ultimately, creating a "data
ecosystem".

mark



More information about the Python-ideas mailing list