Here's something else with which to get away from exam marking ... OO-people like method interfaces. If we don't provide a method interface to your object, we get the chant: "that's not very OO therefore it's bad". But the JCSP/CTJ process `objects' we build don't have method interfaces - they have channel ones - so, therefore, the OO-world is puzzled. When we javadoc the sources, nothing is produced to document those channels - so all the dynamic semantics of our processes are invisible. Somehow, we need to promote channel interfaces to first-class citizens, recognised by javadoc (with some suitable doclet plug-in?). JCSP/CTJ uses old-style method intefaces, but only for static configuration - before and in between process runs. If you take a group of OO-infected individuals, sit with them for about an hour and explain what channel interfaces are ... almost all can be won around ;-) What needs explaining is that we define components (i.e. processes or `active' objects) in terms of their behaviour to a defined interface. That interface does *not* consist of calls to methods on other objects (or Java interfaces representing those objects) or method invocations on itself. It consists of a set of wires (i.e. pins or channels), which are third-party `passive' intermediaries later used to connect components together. This is how hardware works - so we have a simple analogy. A hardware component is defined to behave with respect to signals received and generated on its connecting wires. It is not defined according to how it operates another hardware component. Hardware components can be reused in any context that allows them to be wired together (although not always sensibly, of course). Channel interfaces work the same way. Components read/write their channels - that's as far as they can see and that's a good thing. It eliminates the tyranny of magic names (e.g. in the `observer' OO-design pattern, the observer has to implement method names chosen by the `reusable' library. If I'm designing a component, I want to choose my own names for its formal interface! The implementor of my component needs to know those names, but I don't want to impose them on the user. Name knowledge is localised). Another benefit: deeply nested sub-systems communicate with each other directly over channels - with none of that trivial method copying of messages up and down the object hierarchy. Channels decouple processes in a way that object method interfaces do not. That makes things so much simpler. And simplicity is the message of Occam's Razor ... And there are some much more significant benefits ... another time ... The only problem with channels is that they are a bit low-level. We need higher-level channel concepts - like the CALL channels of occam3 (which look a bit like method interfaces, so the OO-people may be fooled, but which definitely aren't!). And occam3 CALL channels need improving. Oh yes, and they also need implementing ... But there is something fundamental to explain about channels-versus-methods. We need to do this explaining!!! Cheers, Peter.