[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Channels versus Methods

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


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