[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: JCSP Advice anyone?
> I agree with Bernhard that you should take a look at the call-channel
> concept - the only problem is that its a bit long winded to put
I agree :-(
> Ideally I wanted to extend the Java syntax in our (the now
> expired Quickstone) JCSP compiler to do this much more simply, but we
> had to stop work on it before we got that far. We did however write a
> rather cool Java app to support code generation of complex call channel
> servers in bulk, but I'm not sure how much use that'd be to Ruth as it
> outputs Java.
As I've indicated to Bernhard, I found the learning curve for call channels
steeper than I was happy with; I may well have another go sometime.
> Another approach that might be worth considering is creating a call
> channel interface using a proxy object in a similar way to the Hibernate
> database library. Java Proxy objects allow you to dynamically create a
> Java interface and respond to method invocations pro grammatically. I
I'm afraid I don't know Hibernate DB or Java Proxy objects.
> don't even know if C# supports this, but I'd be surprised if it didn't.
C# is actually a very simple language; there's C++ stuff that's not in C#.
For example, no multiple inheritance, there are no "bit" types or unions.
At a guess, a proxy object might map onto an Interface variable? That is, a
variable of type "interface I"?
> It does however depend on how bothered you are about efficiency. It's
> also a bit complicated - but more fun :). If you're feeling really
I'm afraid complicated == more chance of failing == not going there. There
are too many risks to this project already :-(
> adventurous you could use reflection (and possibly method annotations)
> to generate the necessary classes/interfaces statically at build time,
> which would get around the efficiency problem...
I'm concerned about efficiency in some areas - communication, for example,
but not others. It depends. I suspect efficiency is moderately important in
> One thing that'd might make things easier (i.e. less long-winded) might
> be to write a class that extends CSProcess that just takes a delegate
> and calls it in its run method. It'd then be easier to create processes
How would you use this?
> with less code - I have to admit I haven't fully thought this approach
> through as I'm not really that familiar with delegates.
> Also remember that you don't have to use Parallel or ProcessManager at
> all if it's a real pain, you could just start threads in the normal C#
> way - the CSP synchronization operations will still work.
That's good to know!