Re: Inheritance and active objects

[Mark@xxxxxxxxxxxxxxxx (Mark Ian Barlow)]

In message <9612181934.AA25083@xxxxxxxxxxxxxx> phw writes:

(heavily edited, just the bits I want to comment on, I have no argument
with the rest)

<snip>
> Recapping: passive objects encapsulate data and `methods'.  The behaviour of
> the object is determined by its methods.  The methods are just procedures (or
> functions) that are called by other objects.  Implementation of those methods,
> therefore, has to be caller-oriented and not object-oriented.  This means that
> the algorithmic structures within the methods do not parallel the behavioural
> specification of the object and that they are hard to design and prove.
>
> Whereas: active objects also encapsulate data and their managing algorithms.
> These algorithms are expressed through local flow(s) of control and directly
> reflect the behavioural specification of the object -- i.e. the algorithms are
> `object-oriented'.  This makes for simplicity.

Yes. Couldn't agree more. Active objects (processes) capture real object
behaviour better, *but* when active objects act as _surrogates_ for real
things, (with mapped I/O) many of their implementations will consist of
multiple, fairly well decoupled state machines.

Passive objects would be good for this because of their encapsulation property.
Occam 3 MODULEs would do nicely here, they tie free variables to a sub-set of
procedures and keep them safely together.  I do this at present with carefully
chosen fold comments, and it's a MAJOR PAIN in a multi-programmer project.
                                 ~~~~~~~~~~
Ok, that's encapsulation, what about inheritance?  It's a static property, and
hence can be "written out in long-hand". We'd prefer not to, as we know our
own fallibility, but it could.  OO-polymorphism, however, is a different matter.
I would submit that dynamic binding is pretty useless without dynamic memory.
Processes, built from modules, ideally with inheritance, are all that is
needed in occam *until* that bullet is bitten.


<snip>
> But sub-typing inheritance on active objects is not straightforward!  Consider
> an active object with a channel interface.  The responsiveness of that object
> to one its channels does depend on its state.

Surely this is true for most (practical) passive objects too, however much we
might wish it otherwise... That's where the OO bugs bite.


<snip, Re: active objects>
> Where `inheritance' (of a different kind) may be useful is for inheriting
> interfaces.  It would be very nice to have an algebra for constructing
> new interfaces from old, without having to write out laboriously all the
> old bits we wish to reuse unchanged.  It should be possible to eliminate
> bits of exisiting interfaces that we don't need.  We need to be able to
> take (disjoint) unions of interfaces (being careful about name clashes),
> as well as intersections and subtractions.

Yes,yes,yes,yes,please,please.

> Java already has some of this with its IMPLEMENTS mechanism.  Adding an
> INTERFACE algebra to occam (or our active Java objects) may be *much* more
> significant for re-use than worrying about the absence of an `inheritance'
> mechanism.  The result is not a sub-typing relation, but so what?

I think that this means we want protocol nesting. I do this sort of thing
at present, ad-hoc, by slicing 'n diceing variant protocols using my ocpp
pre-processor.  That's primarily what I wrote it for, and it's been
invaluable, but I'm well aware that it's a horrid hack. A more elegant
solution would be very welcome; how about an outline suggestion, Peter?

-- 
Mark Ian Barlow                Non-Linear Control Consultants Ltd.
-----------------------------------------------------------------
Mark@xxxxxxxxxxxxxxxx            Voice / Fax: +44 (0)1207 562 154