[Python-ideas] Message passing syntax for objects

Mark Janssen dreamingforward at gmail.com
Mon Mar 18 21:42:46 CET 2013

> OK, let's use your own example, which you keep reiterating:
>>>> 42 >> MyCollectionType  #would add the object into your collection:  *poof*: no more random syntaxiis for putting things in collections.\
> This solves the problem that list.append, set.add, etc. all look completely different. Great.
> But what if I want to extend instead of appending? If you say "well, another sequence extends instead of appending", then how do I create lists with lists in them? For that matter, how do I insert at a given position, or replace a slice, or… anything besides the default? The obvious solution is that you pass some kind of wrapper message:
>     Extender(lst2) >> lst1
>     Inserter(3, lst2) >> lst1
> But now, you're simulating separate methods by using type-switching. That's about as unpythonic as possible. And if you think about it, how can you write Inserter(3, lst2) in this everything-is-a-message syntax? It's going to get really ugly without a lot of sugar. Unless you curry the messages:
[...snipped several pages...]

All that is very good analysis.  However, these data types you talk
about, I'm gong to argue are explorations from the journey of computer
*science* which are suboptimal.  But to say suboptimal I have to
suggest the context in which I'm optimizing.  That context is creating
the idea of a data universe and ecosystem where the ideals of OOP and
re-usability come out of dreamland and into reality.  And the only way
to do that is to start at the *bottom* and work upwards.  That is to
define the fundamental unit, to re-evalutate the fundamental Object.
But to figure out that you need also the fundamental communications
pathway -- how those fundamental objects will interact.

The questions for this data universe can be boiled down to only a few:
 what event necessitates the object/node creation?  What is the
relationship *between* objects?

At least that's the start of what I'm calling a unified data model.


More information about the Python-ideas mailing list