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

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

Hi,

Neil wrote:
> So you are suggesting a protected schedule() method that simply calls
> the Alternative.schedule() package-private method?  I think that would
> make sense to go in Guard and, as you say, it should allow new guards to
> be implemented.

Don't understand this?  The Guard abstract class has package-only visible
abtract methods enable/disable.  These must be implemented by any new
synchronisation objects wanting to be ALT guards - so, at present, they
have to be in jcsp.lang.  To allow them to be added in user-provided
packages, it's these enable(Alternative)/disable() that need to be made
protected.  Other code implementing the synchronisation actions of the
new objects will need to invoke schedule() on an Alternative object
supplied by enable(...).  So, yes, the schedule() method of Alternative
would need to be made protected as well.  But schedule() shouldn't go
into Guard ... as a method?!!

Hoefully, that would be all?  Inheritance still scares me hugely ...
we must be *very very very very* careful to control visibility and
the mechanisms in Java are not sufficiently flexible ... imho.

Also, anyone tinkering with Alternative does so at their peril!!

Cheers,

Peter.