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
|