RE: Channels versus Methods

["Umland, Thomas" <Thomas.Umland@xxxxxxxxx>]

Gerald,

thank you for your comments!

...
> Hmm, this is always a drawback. Each channel input output pair must match
in
> the application. If the programmer forgets to put a read() or write()
method
> somewhere in the program then this program may hang. Isn't this why we
want
> to use CSP channels? Forgetting reads or writes results in wrong events,
but
> those are easier to trace than tracing bugs with monitors. The programmer
of
> the server application also creates the CALL Channels and must know how to
> communicate with the CALL Channel at the client side. Is this really a
> drawback or just a matter of taste? However, I like your idea to make
things
> safer.

Of course the programmer is responsible for the correctness of his code. 
Let's take a look at the code example of your previous mail:

                // the callMethod method performing z,w = f(x,y)
                public void run() 
                {
                  callchannel.read(x,y);
                  z.value = (x.value + y.value)/divideFactor;
                  w.value = z.value > 10;
                  callchannel.write(z,w);
               }                

In this run-method you have to write an explicit pair of read/ write methods
at the beginning/end of your method. Of course, if you forget the first
read, you cannot process the corresponding data (that's an obvious mistake).
But you could easily forget the last write without noticing it. In this case
it is better, if you have a construct where the compiler can check, that you
realy return a value (BTW it will also tell you if you forgot the read and
therefore an object that you used in the method body was not initialized).

...
> The nice thing about CALL channels is that you can use other names than
just
> 'write', such as calculate(..,..,..), closeValve() or processQuery(..),
> which makes the code better readable.

I agree, it would be very comfortable, if you could choose arbitrary names;
this is not possible in my approach.
If I am right, the names for call channel operations in occam3 are "call"
and "accept". We could use this names or think of even better ones; that's a
matter of taste (the names "read" and "write" are just a first try).

...
> Has the channel two read methods?
> 1. Object read()
> 2. Object read(CallChannelFunctionInterface function)

At the moment that is true. For a final version call-channels and ordinary
channel must be seperated into different classes. (I just took the available
code to integrate and test my concepts and didn't consider any beauty
aspects)

...
> For each CALL channel you need to create a class with an accept() method.
> The tasks of the accept() methods are invisible for the server. However,
> decisions that are taken by these methods may depend on the state of the
> server or on the states of other accept() methods. They do not share the
> state of the server and sharing states makes it complex. This is why
reading
> and writing by the server is practical.

You could do the interface implementation as an inner class. Can inner
classes use "global" variables and share the state? (Does anybody know?)  Of
course you can also use the same accept-method in different channels (if the
processing tasks are identical). My "PileOfChickens" implementation is a
quite complex example; normally the implementation would only contain a
single accept-method. 

> What must be done if one wants an Object accept(Object in1, Object in2,
...)
> method instead of accept(Object in).?

This is an advantage of your approach and a drawback of JCSP. In JCSP you
have to encapsulate two and more parameter objects in a single "transmitter"
object.

> Does this also work for ChannelInt and all others?

Of course it will! But I just did experiments with "general" object
channels. 

> You are using dynamic binding (or casting) in the accept() method. This
will
> not only be checked by the compiler, but also checked at run-time. A wrong
a
>argument and things goes wrong. Is this a drawback?

If you have special channels (like Integer-channels) you don't need the
casting. Different channel types must be included in a final version. Again,
this is only a case study ...

Thomas