RE: Objects, processes, and encapsulation

["Hilderink, G.H." <G.H.Hilderink@xxxxxxxxxxxxx>]

Marcel, 

The callback you described is often used and works safely within one
sequential flow of control. Although callbacks seem to be simple and useful
in a single thread, they are an important source of complexity in a
multithreaded environment. When I use monitors I have to be careful with
callbacks. Synchronized callbacks can easily deadlock on monitors by the
caller. In order to do it right, I need to understand/trace all the calls in
one flow of control and I need to understand/walk through multiple objects.
This is complex, unnatural, and most important of all this is no longer
object-oriented, but thread-oriented (threads are not objects!). 

Processes should behave differently. Processes are sparing partners. Like in
boxing, if a process punches another process it may expect a punch back. If
a process punches the other process then during that punch it will never get
a punch back as a result of that punch (so no callbacks within a call). If a
process punches and receives a punch back then the punch back must be the
result of a previous punch. In this case, these punches are in parallel and
this is asynchronous behavior without buffering :).

Punching is comparable to calling methods, sending messages, or simply
engaging in an event. A punch is a method call that always terminates. 

The Process's run body should call methods and accept method calls. This is
where state-charts come into action! The process's run body goes from state
to state and the transitions call or accept methods. As in state charts
there is no need for nested calls. ALTs can be very useful as part of the
state machine. Explicitly accepting calls seems to complicate things, but it
is not. A nice feature of accepting methods is that the state of a process
can only change during that event as a result of calls by other processes. 

We need to learn more about this approach. We need to learn more about
call-channels since they will be used more often than primitive channels in
business applications. We need design patterns using call-channels. I agree
with Johan, this is important and this should be at the beginning of the
book.

Gerald