RE: Channels versus Methods

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

> OO-people like method interfaces.  If we don't provide a method interface
> to your object, we get the chant: "that's not very OO therefore it's bad".

That is exactly the answer I get from my OO-colleagues when telling them
about JCSP.

But CALL-channels would even simplify the handling of channels for us "OCCAM
boys" in situations where we now need two channels: one for requesting data
and one for getting the data.
If you remember the "Whot, no chickens" example: in the communication of the
Phils with the Canteen it would be easier if we had only one channel (call
it food) instead of two channels for request and deliver.
Writing 
	plate = food.call (); // call for a chicken
is more comfortable than writing two communication statements
	request.write (dummy); // tell the canteen-ALT that we would like to
get a chicken
	plate = deliver.read ();   // wait for a chicken to be delivered
where the compiler of course can't check whether the programmer forgot the
second read() or the first write() what would of course cause a deadlock. 

So, a combination of method calls on the "client side" of a channel with
ALTing on the "server side" would be nice, that is exactly what
CALL-channels provide. 

>> Oh yes,
>> and they also need implementing ...

I would like to use this concept in one of our projects. Therefore I
actually started the implementation of "CALL-channels" together with a kind
of "remote channels" on the basis of the JCSP sources. It doesn't seem to be
too difficult (at the moment ;-) ).

Thomas

=================================================
Dr. Thomas Umland, Deutsche Telekom AG, Entwicklungszentrum Nord,
Willy-Brandt-Platz 3, 28215 Bremen, Germany
Tel.: 0421/3799-423, Fax: -379, mailto:Thomas.Umland@xxxxxxxxxx