Re: Objects, processes, and encapsulation

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Ian,

> ...Don't shoot me, I'm just trying to play devil's advocate ...

:)

> All that I meant was that these guys might claim that, in order to
> provide services, you still have to respond to a request by executing a
> procedure (which might be just one line, removing any purpose to capsule)
> with access to local state ...

We're talking about a *process* providing services.  Sure, it responds to
client requests by executing procedures (or one-liners - no matter) that
access and may modify local state ...

>                             ...  And that the _all-important_ difference
> is that you can decide if/when/how you respond next time.

More specifically, the all-important difference between a *process* response
and an *object* response (via method invocation) is that the process is
in full control of all its responses - in particular the order in which
they happen.  It can, of course, make responses (explicitly) in parallel.
Either way, the logic (semantics) of process behaviour is independent of
the actual context in which it is placed - it is analysable (constructable)
from purely *local* information.  That's what makes processes manageable
and systems scaleable.

It's strange what the Object Orientists have achieved ... they have managed
to make serial programming as dangerous as unconstrained concurrent
programming.  We must be aware of these dangers and take precautions
... but this adds complexity on a par with trying to control concurrent
algorithms with simple locks.

They have made serial programming hard indeed.  We have to view each
collection of object methods as invocable with arbitrary interleaving ...
with that interleaving happening both between the various invocations and
in the middle of them (with external method calls marking interleaving
points - call backs)!  That's what makes OO hard and systems unscalable.

They did this by going for the natural concurrency model of the way things
work ... but only half carrying the idea through.  They have managed to get
the worst of all worlds: hard serial logic and hard concurrent logic.

Whereas, for processes, we get easy serial logic (the "S" in "CSP" stands
for Sequential) and easy concurrency.

IMHO :)

Peter.