[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JCSP - Interpreter (& too restricted visibility of classes in JCSP package)
The problem lies in defining our own Guard that is not in jcsp.lang.
The alt.schedule() method is package private, so although we can create
our own enable and disable methods, we cannot explicitly call
alt.schedule() to inform the Alternative our Guard is ready. Under
nearly all circumstances this is not a problem, as the Guards supplied
do perform most tasks that we need. However, there does seem to be a
slight shortcoming with this approach. This leaves us the option to
make alt.schedule() public (very nasty), or provide a mechanism to allow
all Guards, even outside of jcsp.lang, a mechanism to call
alt.schedule() somehow. Making it protected simply exposes it to any
child classes, and Guards do not inherit from Alternative. My first
guess was to put a protected method in Guard, as it would provide us the
necessary mechanism; guard.schedule() simply calls alt.schedule(). It
is does expose alt.schedule() somewhat, but only to Guards. As long as
great care is taken when writing our own Guards, then the there should
hopefully be little or no risk.
So Alternative will not be tinkered with, and only some new methods need
be added to Guard. It is unfortunate that Java doesn't provide some
mechanisms to allow cross package visibility. .NET has the internal
keyword (dll or exe level visibility) and friend classes similar to C.
This solves some of the problems that Java has, but really opens up
numerous others. My recent reading on .NET reveals that it will be
possible to actually add methods to existing classes if you wish, so
string could have a new method ReverseToLower() added to it. Not sure
as yet if I like this idea as yet. Anyway, I hope this clears this up.
School of Computing
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
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!!
This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the
University's system is subject to routine monitoring and filtering by the University.