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
|