[Python-ideas] Message passing syntax for objects

[Mark Janssen]

>>> My answer to that question would be that it *did*
>>> catch on, it's just that we changed the terminology.
>>> Instead of message passing, we talk about calling
>>> methods.
>>
>> Yes, but this is where it breaks the OOP abstraction by 90 degrees.
>> By using function calls, you're telling the machine to do something.
>> But when you want to pass something to an object there should be a
>> natural way to do this for every object.  By using methods you pollute
>> the concept space with all sorts of semi-random (i.e. personal) names,
>> like append, add, enqueue, etc.
>>
>> This proposal would not only make a consistent syntax across all
>> objects, but train the programmer to *think* modularly in the sense of
>> having a community of re-usable object.  I.e. "What should I do if
>> another object passes me something?".  No one thinks this now, because
>> the programmer expects new developers to learn *their* interface!

> I'm struggling to understand what you mean (and I don't seem to be the only
> one).
> As far as I can tell, you would replace an object with N methods by an
> object with one huge method (ProcessReceivedMessage say) which deals with N
> cases.
> (Not an improvement as your code has become much less modular.)

No.  If the language provides a data-passing syntax (like << and >>),
then programmers would design their object hierarchy with this idea in
mind.  If you have N methods (N > 1) for passing data to an object,
I'm suggesting you haven't designed you object classes properly.

> And instead of semi-arbitrary method names, you have semi-arbitrary messages
> (names, numbers or whatever).
> Just as much of an interface to learn.
> Am I missing something?

Yes, the data passing syntax (<< and >>) would be the same for all
objects because the language itself would be providing the primary
interface between objects.

> Can you give a semi-concrete example using pseudo-code, where your way
> clearly does something which can't be done as well (or at all) using method
> calls?

I will work on it.  What I'd really like is to refactor all the Python
standard library code to see how much simpler it would be.

Mark