Hi Thomas, > > 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. What do they say if you point out some of the problems with method interfaces? (And my email didn't include the worst problem ... which I will write up when I've finished my pile of exam scripts :-() > ... 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 ;-) ). That could be fun ... thinking on the fly ... a CALL channel is a passive synchronisation object: the caller sees a call-interface and the acceptor sees an accept interface - e.g. interface ChickenPlease { public int call (int nChickens); } interface ChickenServe { public int accept (); } The implementing class contains a pair of channels: class ChickService implements ChickenPlease, ChickenServe { private final One2OneChannelInt toCanteen = new One2OneChannel (); private final One2OneChannelInt fromCanteen = new One2OneChannel (); public int call (int nChickens) { toCanteen.write (nChickens); return fromCanteen.read (); } public int accept () { int nChickens = toCanteen.read (); fromCanteen.write (nChickens); } } Except that that's no good for the acceptor who has to process its own state depending on the values recieved and generate an answer ... which the above does not :-( ... Hum ... so drop the accept interface and let the server access the channels directly? Then, the client-side code would make the OO-people happy: ... int nDelivered = ChickenPlease.call (2); ... leaving the server-side OO-people miserable ... oh well: switch (alt.fairSelect (gotAtLeastOneChicken)) { case PHILOSPHER: int nRequested = ChickService.toCanteen.read (); if (nChickens >= nRequested) { // doing the accept nChickens -= nRequested; // means processing ChickService.fromCanteen.write (nRequested); // local state } else { // (e.g. nChickens) nChickens = 0; ChickService.fromCanteen.write (nChickens); } break; case COOK: ... break; } That's not terribly nice! Do you have something better -- e.g. that makes an accept interface extend Guard so we can ALT on it directly?? Note that CALL-channel servers that will never block their callers can be simply implemented as passive Java monitors (all-sync methods) - e.g. the jcsp.awt.DisplayList. But we need something more general ... ??? I still think we should educate the OO-world rather than pander to it. And a clean generic way to do CALL channels in Java would be great! Cheers, Peter. PS. "remote" JCSP channels would also be a winner. I had a student project this year that's `sort-of' done it and Chris Nevison at Colgate also has a student working on it. We should pool our experiences ... and I think Gerald Hilderink's CTJ channels have had remote drivers for some time!