Hi Anne (and Neil),I am led to believe we can add generics, then compile with the version 1.3 flag and all should be well. Although I have never had time to try. It is a nice feature to have generics, something I added to the .NET version, as well as an overall Channel interface also. But it is a matter of priority at the moment. Unfortunately, although Peter did credit me with doing work bringing JCSP forward, at present I have being doing little because of other commitments, and really Neil is working himself somewhat. The first major task was amalgamating the two different versions of JCSP together, then adding some more key features (Extended Rendezvous and Posion). My mobile package will be added and there is some general house keeping needing done also. Then we have a number of other tasks we have previously discussed, such as generics. So yes, I would think once we feel happy with what we have, generics will be added.
Regards Kevin Chalmers Research Student School of Computing Napier University Edinburgh Neil Brown wrote:
Hi Anne,There are lots of possibilities once we move to using generics. The reason for not including them is backwards compatibility. The current Kent JCSP version is 1.1-onwards compatible I believe, and the next version will become 1.3-onwards compatible. This is partly for using Java on mobile devices I gather - something Kevin Chalmers knows more about than me. Maintaining two versions of JCSP (a 1.5 version with generics, and an older version without) would be tricky, so we currently aim for the broadest user-base that is sensible - and that means being compatible with Java 1.3.Neil. Anne van Rossum wrote:Dear list members, This is about the Quickstone version of JCSP, but I guess it also applies to yours. Is there a reason not to use generics? ___________________ I mean, One2OneChannel etc. do not derive from some general Channel interface, while they all have to have a in() and out() method that returns a ChannelInput and a ChannelOutput. public interface Channel<I extends ChannelInput, O extends ChannelOutput> { public I in(); public O out(); } ___________________ Likewise ChannelOutput only does have one thing to carry, so it's naturally to give the one extending the class the ability to restrict the type of object that can be transported in the following way: public interface ChannelOutput<O> { public void write (O object); } This can be used by extensions, although not for basic data types (like int), e.g. in the following sense:public interface ChannelOutputInteger extends ChannelOutput<Integer> { public void write (Integer integer);} ___________________ I hope you see enough reasons in terms of extendibility that you consider this option. Kind regards, Anne
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.