Message passing rather than object orientation

Marcel Weiher marcel at metaobject.com
Sat Oct 13 11:03:27 UTC 2001


On Thursday, October 11, 2001, at 08:53 PM, Ken Kahn wrote:

> Andres Valloud  wrote:
>
>> However, what I find very interesting is that we say "In a
>> Smalltalk system everything is an object, and everything gets done when
>> objects send messages".  IMHO, that everything is an object is
>> insignificant when compared to the requirement that everything gets 
>> done
>> by sending messages.
>>
>
> I think this is a GREAT insight.

Yes, though I actually think our idea of what/why an object is also 
needs refinement (see Alan's remark about Squeak being too Platonic).

>  In my paper, "Objects - A Fresh Look",
> ECOOP '89
> http://www.ifs.uni-linz.ac.at/~ecoop/cd/papers/ec89/ec890207.pdf
> I tried to argue for a much more expanded notion of objects but what I 
> know
> releasize is that I was really writing about was more general message
> passing.

Yes, I've also been arguing for that with HOM, Higher Order Messaging.  
When you think of 'real' messages, you realize that they can be routed, 
stored, forwarded, broadcast, multicast, packaged, morphed, repeated, 
etc.  In Squeak, a message can only really be sent/delivered to a single 
recipient, right now.  As soon as we do something as simple as 
multicasting a message, we revert to blocks.  When we broadcast, we send 
notifications.   More complex message patterns are interspersed with the 
objects and computations that are to be performed (see simple things 
like #printOn: and #storeOn:), meaning we remain stuck at a fairly 
low-level of abstraction.

HOM is one way of dealing with this, remaining completely in the 
messaging domain.  Another, probably more elegant, approach would be to 
change the way we specify recipients.  Instead of just being able to 
specify a single named object, we should be able to specify a 
propagation pattern for the message.  The dotted notation used in 
ThingLab is an interesting starting point, as are the propagation 
patterns in adatptive programming.

>  You send a message and maybe an object generates a reply but maybe
> several objects receive the message and collaboratively or competively
> compute a reply.

  tree1 fringe isEqual: tree2 fringe ...

>  And a reply might be a single message or a stream of them.

My EncodingFilters ( previously FilterStreams) are one attempt at 
dealing with "replies" that consist of streams of objects.  'Classic' 
call/return can't really deal with passing stream replies 'back' to the 
sender, so the solution is to pass the result 'forward' to a specified 
target instead, just like the pipes/filters architectural style.  So 
instead of the following:

	result := someObject msg.

someObject>>msg
	^msgResult

you have something like this:

	someObject writeOn:target
	result := target contents.

someObject>>writeOn:target
	target write:msgResult

Of course, forward-passing of results is more cumbersome in languages 
that are built around call/return.  Also, it is an explicit change in 
coding-style, you can't interoperate protocol built for forward-passing 
with methods built for call/returns.

What would be needed is some adapter code to automatically convert 
call/return code for use in a forward-passing context and vice versa.  
It might be neat to examine changing ^ to mean "send-back" again.  That 
would allow the same method body to be used both with call/return and 
forward-passing.

someObject>>msg
	^msgResult

A call/return proceeds as usual, but a forward-return has to set up a 
'result-sink' in the method-context that accepts the 'send-back' message.

Of course, there are also implementations that are less intrusive for 
the current system.

[..]

>  And maybe an object has more than
> one "mail box" where messages arrive. And so on.

Yes.  Collections are an easy example where you might want multiple 
mailboxes.  One for all the objects stored in the collection, another 
for meta-information about the collection, such as its size or wether it 
is empty.

Marcel

--
Marcel Weiher				Metaobject Software Technologies
marcel at metaobject.com		www.metaobject.com





More information about the Squeak-dev mailing list