Re: occam and inheritance and delegation

[Oyvind Teig <Oyvind.Teig@xxxxxxxxxxxx>]

    On Thu, 29 Oct 1998, Oyvind Teig wrote
>   On Wed, 28 Oct 1998, Jim Moores wrote
> > On Wed, 28 Oct 1998, Oyvind Teig wrote
> 
> 
> > Sirs
> > 
> > Q1. Does occam support inheritance?
> >     In its own way I 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.  

If I override MethodA in an inherited object's MethodA, I have to
do it explicitly, by writing the code of the overridden MethodA. 
And I have to explicitly both declare and "new" the inherited object.
So we have to do a lot of programming in the real OO case as well.
I cannot see that there is much difference here. Please explain.

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

This is what I have always missed in occam. 
A 'catch all', 'catch the rest', 'send all', and 'send the rest'.
In this way we could come closer to building generic buffers as well,
at least protocol tag-less occam code in the buffers. If somebody
nice introduced this into the language, wouldn't it be easier to
sell? And, it wouldn't infer dynamic memory handling either.

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

Disagree. This is not bending occam at all, this is one of the things
that comes out of elegant design: communication over named channels.
Isn't this what Hoare changed from the 1978 to the 1985 version of
CSP?

Also, is delegation and callback the same?

Another question: the new word "broker" - would it be brokers
that we would hang on the other end of the CHAN array? Is this
right usage of term?

-------------------------------------------------------------------
I'm giving a lecture "occam - a dead end" at

http://www.oslo.sintef.no/fora/kalender/ituf_dagen_innbydelse.html

That's why I need to get these modern terms right, and I draw
on this group's expertise. Thanks!

-------------------------------------------------------------------
 Oyvind Teig                              oyvind.teig@xxxxxxxxxxxx
 Autronica AS                             oyvind.teig@xxxxxxxxxxxx
 7005 Trondhem                               Tel.: +47 73 58 12 68
 Norway                                      Fax.: +47 73 91 93 20
-------------------------------------------------------------------