Channels versus Methods

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

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.