Instead of serializing the processing in order to meet the needs
of the communications, it is more advantageous to consider supporting
asynchronous communications. The 'traditional' way to provide
asynchronous communication is based on the message metaphor, as in
Actors [AH87].
Note: in Smalltalk, messages provide support for late binding, not
for distribution. Smalltalk messages are synchronous. The semantical
difference is however not essential since distribution transparency
may be seen as a form a late binding.
Message based interactions are badly suited for static typing:
requirements that a given server could set upon its clients concerning
the type or the contents of the messages it is committed to accept,
can only be enforced dynamically.
Strong typing, especially aiming at enforcing behaviour
compatibility (see 1.2.3.b), is better served by the function call
than by the message passing metaphor. The reason for this is that
functions define a syntactic scope, and messages don't. A function
call actually encapsulates two messages: one at initiation and one at
completion. These delimit the function scope. In the message passing
model, similar protocol information has to be maintained in separate
state machines, under the developer's responsibility, not the
language's.