Hi Mira:

I have thought more about event firing in APPCs and had the following
idea about using strategies as guards for APPC entries:

Some APPCs have delicate needs to be informed about certain
traversal events. For example, the Connectivity APPC
would like to be informed when we enter an Adjacency the first time
coming directly from Graph. You proposed a way to do this in
http://www.ccs.neu.edu/research/demeter/design-decisions/plug-and-play/APPCBeans.ps

In your solution the Marking APPC informs the Connectivity APPC.
This creates a dependency between Marking and Connectivity
since Marking sends an event to the listeners and Connectivity
contains code that reacts to that event.

There is a better solution by allowing APPC entries
to be prefixed by a strategy:

APPC A (strategy s1) ...
  guard s before <C1> {code}
  guard s after  <C1> {code}
  guard s before -> <C1>,<l>,<C2> {code}
  guard s after  -> <C1>,<l>,<C2> {code}
  ...

s must be a substrategy of s1.

This leads to a third use of strategies:

The other two are: super-iterators, participant definers.

Meaning:
  guard s before <C1> {code}
  Execute code only if <C1> is entered during subtraversal s.


  guard s before -> <C1>,<l>,<C2> {code}
  Execute code only if the strategy graph edge is entered 
  during subtraversal s.

APPC Connectivity {
  Input-Class-Interface
    from <Graph> to <Adjacency>
  // Behavior
  int count;
  init {count=0;}
  guard from <Graph> to-stop <Adjacency> 
    at<Adjacency> {count++};

It is important that the guard be put in front of the entry.

APPC RestrictedCounting (strategy s) {
  int count;
  init {count=0;}
  guard s1 at<A> {count++};
  guard s2 at<B> {count++};
  at<A> {code1};
  at<b> {code2};
}

Here we could not restrict s since for code1 and code2 we want
s and not s1 (or s2).

========================================
Complete Example:

APPC Marking // Mira's program
  Input-Class-Interface
    from <Graph> via <Adjacency> ...
  Output-Interface
    {
  // Behavior:
    List visited = new List();
    // I think the following part can be improved too
    vetoFrom<*>To<Adjacency>(EdgeEvent ev) {// traversal will ask for veto
      <Adjacency> adj = ev.toNode(); // not structure-shy?
      boolean marked = visited.includes(adj);
      if marked {
	throw new DoNotContinueException(this);
      }
    }
    at<Adjacency>(NodeEvent node) {
      visited.addElement(node);
    }
}

APPC CycleCheck {
  Input-Class-Interface
      from <Graph> via <Adjacency> ...
  Stack cycle = new Stack();
  at<Adjacency> {
    cycle.addElement(host);
    // check for cycle
  }
  doneAt<Adjacency> {
    cycle.remove(host);}
}

APPC Connectivity {
  Input-Class-Interface
    from <Graph> to <Adjacency>
  // Behavior
  int count;
  init {count=0;}
  guard from <Graph> to-stop <Adjacency> 
    at<Adjacency> {count++};


We would like in general to follow the above approach to
reduce dependencies between APPCs:
only clients should specify events they are interested in.
And those events should ideally be in terms of the traversal APPC
and not in terms of other APPCs.

The traversal APPC has a special role since we have a rich language
to talk about events and we need to express the
events on the client side only.

-- Karl