Hi Peter,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.
Regards Kevin Chalmers Research Student School of Computing Napier University Edinburgh P.H.Welch wrote:
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.
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 lossor 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.