Re: Objects, processes, and encapsulation

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

Ian,

> > Point 2 is why "processes" are very different from "objects" (whose
> > attributes we must treat as global variables :( :( :( even when "private"
> > - and whose methods are there to be invoked by anyone who can see it).
>
> They might argue that, once you design a process to provide services on
> demand, encapsulation is still vulnerable to client requests, especially
> if design is poor. As you said, it's the very presence of a local thread
> of control that affords the possability of extra protection.

How can they argue that "encapsulation is still vulnerable to client
requests"?  There's no way a client can impact the (encapsulated) state
of a server - the client has to get the server to do that.  If the server
refuses to listen to the client, there's nothing the client can do about
it!  Process state is invulnerable - only the process itself can change it.
If my server (process) always guarantees service to clients (e.g. it fair
ALTs or FIFOs them), then it never refuses requests - but, in that case,
I have deliberately programmed such "vulnerability" (a strange word for
this context).  It's still in full control of its response though - not
the client!

> > Humm ... as someone mentioned, Tom's paper focusses on inheritance of
> > process (i.e. "active object") *interfaces* - which are just the set of
> > external events (channels etc.) with which it engages.  Inheritance of
> > process behaviour comes simply by reusing old ("super") processes intact
> > and modifying their behaviour by connecting them with some additional
> > ones.  [Actually, it's not quite that simple - hence his ideas on
> > splittable variant channels ...]
> 
> But the essence of a process surely is it's thread of control. Can we
> provide some (formal) mechanism for extending/modifying that?
>   We can define new processes by composition with/of old ones, but we
> can't add/change some feature to/of an existing process within its
> context, eg by adding a clause to an ALT to respond to input on an extra
> channel.

I think I explained how to do this (for JCSP) in my last posting ... and
also refered to Oyvind's small paper at CPA-2001 ...

>   Then there's multiple inheritance...
>   Personally, I'm happy as we are. But the OOPosition will claim it's a
> comparative weakness. (Personally, I think inheritance is over-rated
> anyway...)

I agree - I've always found simpler ways to reuse (process) components than
extending/overriding their internal behaviour ...

> > Better go read Meyer's book I suppose ...
> 
> Once read, it remains useful for standing on to reach high places. (~1200
> pages.) You may feel the need to nut something/one afterwards.

I don't like heights.

Cheers,

Peter.