[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.
Mark
More information about the Python-ideas
mailing list