Doug turned me around again. Now I argue
against strategies in APPCs, only for strategies in the maps.

Here is Doug's argument:

He feels that there is duplication between strategies and interface class graphs.
He proposes that we make the interface class graphs so minimal
that for a traversal APPC the traversal goes from the sources
to everywhere.

In other words, for a traversal style APPC the traversal is always
go everywhere.

Going to the running example in Mira's APPC Java Beans description,
we have a summing APPC that contains a traversal "from Composite to Summing".
We can just as well replace that traversal by "from Item to *"
or simply by using a keyword: "traversal-style" that indicates that we go
everywhere from the source of the ICG.

So we are back to the philosophy:
In the presence of interface class graphs we need strategies
only for the map.

Such a simplification looks very good. We can still do traversal/visitor
style programming simply by using a traversal that goes everywhere.

-- Karl

=======================
In defense of traversal strategies:

We have been talking of using traversal strategies only in
the maps and not in the APPCs themselves.

However, there are several reasons for using strategies in APPCs:

I find it convenient to use traversal strategies in APPCs. Mira and
David also used them in the examples.

Doug was asking whether we cannot just introduce another interface 
class graph for every strategy.
And in the interface class graph, 
going through an instance variable would correspond to following the strategy.

1.
This approach does not work if we have a multi-target
strategy: from A to {B,C,D}. We cannot replace it by one instance variable.
Multi target strategies are quite common.

2.
Also I find strategies to be very convenient for traversing small structures.

3.
Johan made this point: The traversals in the APPC 
formulated for the ICG will be carried out in the 
concrete class graph (or objects of the concrete class graph).
Because the concrete class graph and the interface class graph 
are in a compatibility (or refinement) relationship, we have the
problem of generalizing the APPC-level traversal to the CCG-level.
But this generalization task is done well by strategies:
that is what they were made for.

4.
Also consider the Summing and LimitChecking example. 
There we use a strategy "from Composite to Simple" in the context 
of a recursive interface class graph. 
We want the APPC code to be justified by that recursive structure.

In summary, I think that strategies are very useful to have
in the APPCs directly, not only in the maps.

-- Karl