Hi Mira:

below is a message from a year ago about parameterizing adaptive
programs. The interface class graph helps to localize changes
to lots of individual strategies.

I like your description which says how R1 improves 
the structure-shyness provided by Adaptive Programming.

The text below gives an independent description.

I think we should put Geoff Hulten (a graduate student at the University
of Washington) in the acknowledgments along with Doug and Johan 
since he recognized early on the need for R1.

We should send him the paper for review:
ghulten@cs.washington.edu

-- Karl


Jul 17  1997 new-view

Geoff has made good progress on how to better organize
adaptive programs. He studies the tension between strategies
and encapsulation.

I view the work heading in the direction of "adaptive modules", 
modules for short which we can use effectively in Demeter/Java. 

Geoff writes:
  The interface to a module is a set of collaborating classes 
  and their interrelationships and it's implementation is
  another collaborating set of classes and their interrelationships.

A module has two parts like in Modula-2: an interface part
and an implementation part. (For one interface part we might have several
implementation parts.) Both parts contain a class graph:
The interface part contains an interface class graph which contains
a high-level view of the reusable behavior which is traversable
by clients of the module. The implementation part contains
a detailed, low-level class graph and it contains several strategy
graphs to define how traversals in the interface class graph
are implemented in terms of the implementation class graph.
The edges in the interface class graph are derived edges as defined
by earlier work and implemented in Demeter/Java.

An interface class graph defines an abstraction of an implementation
class graph for the purpose of the reusable module.

What is the gain?
Strategies which use a module have only access to the interface 
class graph. Should there be a change in the implementation class graph
which does not require a change to the interface class graph,
the strategies using the module will not have to be changed.
This helps to localize changes which is also the theme of the
Law of Demeter. (That is why we sometimes refer to this work
as the Law of Demeter for strategies.)

What is the difference to Modula-2.
In Modula-2 the interface class graphs are star graphs: one node with
several outgoing edges. In Demeter/Java, the interface class graphs
can be arbitrary graphs. And of course, Modula-2 has neither strategies
nor objects.

What is the risk?
We have one more level of indirection and we have to learn to work
with lots of derived edges. But the overall gain is significant,
I think. We reuse the concept of class graphs to define the interface
modules.

IMPORTANT:
Please start using this new model of thinking about adaptive programs
as a design tool so that we can gain some paper and pencil experience before 
we decide on an implementation in Demeter/Java.

Please contact Geoff for further information. He is working on a paper
on this topic and he had several discussions with Doug.

-- Karl