Re: occam and inheritance and delegation

["J.Moores" <jm40@xxxxxxxxx>]

On Wed, 28 Oct 1998, Oyvind Teig wrote:

> Sirs
> 
> Q1. Does occam support inheritance?
>     In its own way think it does. 
> 
>     I have PROC Inner, connected via CHAN OF Base in, out.
>     I wrap PROC Outer, connected via 
>       CHAN OF Base in, out *and* CHAN OF Extended ein, eout.
>     Outer intercepts all messages coming on in and sends it
>     over to Inner's-in or processes it itself. I have modified
>     the behaviour.
>     Should the user decide to connect to channels ein and 
>     eout, extended functionality is acquired.
>     We have acquired a kind of polymorphism which is explicit,
>     which excludes use of that word, but anyhow..
>     If a client just sends on CHAN OF Base, it will not know
>     how we have decided to connect it: in one case to Inner,
>     the next case to Outer.

But isn't this the same as simply embedding an instance of one object
(process) inside another and passing on method calls (channel comms.)?
You sometimes have to do this in Java because of the single inheritance,
and its definitely not inheritance. 

Ok, so in occam you don't have to implement a whole bunch of
methods to pass on paramters to the instance, you just connect the
channel.  In this way its easy to get the functionality of extending the
functionality of an object, but only if the extended functionality does
not intersect with the origional functionality:  there is no way to
override _parts_ of the behaviour without programming a server that
intercepts the channel passed on and examines each message.  occam also
has the restriction in a protocol, that there is no 'catch all' for
message tags, so you have to provide code to deal with all possible tags
that might come through.

To me this is not inheritance - you admittedly can provide the same
functionality, with extra programming, but this is true of any programming
language.

>     > Q2. Does occam support delegation?
>     In its own way think it does. 
>     
>     Should Inner decide to have somebody else, or an array
>     of somebody else'es, do a job for it, we could just send
>     an index (over a channel) pointing to which element of 
>     delagatedChannelArray we need in order to have our job
>     done. Inner is, as always with occam, not aware who
>     it is talking to, it may be this proc or that proc.
>     We connect that on the outside.  
>     By the way, what's the difference between delegation and
>     callback?
This appears to be a way of getting pointers in occam - use array offsets
instead.  Again, you can do this kind of thing in any language - bend the
features you have to give you the desired functionality - but not without 
extra programming work.  This extra work is what sets apart a language
that implements a feature and a language that doesn't. 
> 
> Cheers,  
> 
>  Oyvind Teig                              oyvind.teig@xxxxxxxxxxxx
Just my 2p's worth.

Jim
---
Jim Moores, PhD Research Student, Computing Lab, University of Kent, UK.