Where would you put the return?

Stephen Pair stephen at pairhome.net
Tue May 20 18:25:59 UTC 2003


Anthony Hannan wrote:

>In Squid, selectors will be more than just symbols.  I'm considering
>adding an attribute to Selector to indicate whether it returns a value
>or not.  All subclass/polymorphic methods would have conform to this,
>and all senders would not be allowed to get the value of a
>"procedure-only" selector.  This will speed up returns a little since
>only "function" methods will have to return something.
>
>Cheers,
>Anthony
>

You might even be able to take this farther and generalize messaging in 
Squid such that it always follows a stream like interaction.  A normal 
message send might conceptually look like:

- construct the Message object
- open a bidirectional message transport stream to the receiver (have a 
dispatch and response stream)...the protocol for this might be very 
similar in nature to the way a TCP listening service accepts incoming 
socket connections
- dispatch the message to a receiver via its dispatch stream (using a 
#nextPut:)
- wait for zero, one or more MessageResponses on the receiver's response 
stream (useing a loop that tests for #atEnd and uses #next to fetch 
MessageResponses)

This would of course be optimized for the common case, but this model 
would enable you to make use of arbitrary message transport 
implementations with ordinary looking messaging syntax.  The receiver 
and caller can be local in an image and activated in the same context 
stack, or the recever could be activated in a different Proces, or the 
receiver and caller could be on different machines.  This model also 
accommodates methods that don't return a result, or that return multiple 
results.  The default message transport would of couse be to use the 
context stack's call/return mechanism.

- Stephen



More information about the Squeak-dev mailing list