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

Re: JCSP - Interpreter (& too restricted visibility of classes in JCSP package)

Anne van Rossum wrote:
Dear list members,

The JCSP library is nice. However, for my purposes there is too much
package protected. Is this for some reason?
I am creating a special CSProcess, let I call it an Interpreter. The
Interpreter is decoupled from the application functionality (e.g. it
does have several processes in an array). The Interpreter may take care
of other non-functional aspects:
      * Scheduling: The ParallelInterpreter does have a run() method
        that calls all its processes in a Parallel construct. Other
        interpreters may implement all kind of pool policies. The
        Interpreter can be called a Pool in this scenario;
      * Coupling: Instead of containing an CSProcess array, the
        interpreter may access a pool where processes swim around. It
        can take one that performs fast of about which it has positive
      * Process manipulation: An Interpreter may consider its processes
        and combine them too one new process, before running it:
        Transforming channels to (variable) assignments within the same

To create an Interpreter I want to have ChannelInput's and
ChannelOutput's that carry CSProcess instances. Let I call them
ChannelProcInput's and ChannelProcOutput's. So, the
One2OneProcChannelImpl should implement ChannelProcInput,
ChannelProcOutput and One2OneProcChannel. The methods to overwrite are
only in() and out(): public ChannelProcInput in() { return this(); }
  public ChannelProcOutput out() { return this(); } //and read, write
Regretfully One2OneChannelImpl is package-protected, so I can't extend
it. Neither can I copy its code, because the method schedule of the
Alternative class is not visible either.

Hi Anne,

You seem to be doing some advanced things, but I am not clear why you need to create a new channel. One2OneChannel can carry instances of CSProcess without a problem - you just have to cast the return result from ChannelInput.read() back into a CSProcess (generics are not used in JCSP just yet). What is the reason for needing a new channel?

To answer your original question, things are kept package-protected to ensure some measure of integrity. If you did want to perform an ugly hack of the channels, the easiest thing to do would probably be to write your channel hack in the jcsp.lang package, so that everything package-protected is available. I would not advise doing this though, at least until I can understand your problem more.