Re: Objects, processes, and encapsulation

[p0072370 <ireast@xxxxxxxxxxxxx>]

Peter

I agree with all you say. The problem is that these guys are so 
entrenched! Meyer seems to lead the pack at the moment.

Maybe we should take 'em on on their home ground. But I think we need to 
be armed in advance against the criticisms they'll make in response. 
We're probably weakest on inheritance. If we could provide a consistent 
formal model for that too...

>  2. the data and algorithms of a process are private.  The outside world
>     can neither see that data nor execute those algorithms!
>
>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.

>> 2 Active objects clash with inheritance
>> How do you inherit, and modify, an active behaviour? He criticizes
>> Simula's "inner" construct for forcing a parent class to prepare the
>> ground for offspring. A class should be "open" to modification, but
>> "closed" upon use. Multiple inheritance exacerbates the problem.
>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.
  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...)

>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.

Cheers
Ian


Dr. Ian Robert East

Room T2.10, Turing Building                      0 (44) 1865 484529
School of Computing and Mathematical Sciences
Oxford Brookes University
Wheatley Campus
Oxford OX33 1HX                                ireast@xxxxxxxxxxxxx

2001/2 Term 1 Consultation hours:
Mon 09.00..11.00
Fri 11.00..13.00