RE: Channels versus Methods

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

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!