Hi Doug:

sorry for the delay.

The API below looks good to me. Regarding the returned information,
we would like to get back whether the class graph and strategy graph 
are compatible. You probably know this from the forward sweep?

I-Chen and Bill: how do you like Doug's API. Does it satisfy
your needs?

--Karl

Subject: Re: AP library

Karl Lieberherr writes:
 > Hi Doug:
 > is the AP library ready?

Almost...  I decided to give it a face lift in order to implement the
improvements we talked about (returning a new TraversalGraph object
for each computation, rather than just marking a subgraph which needed 
to be queried).  So the code has changed a lot.  I'm testing it now.

 > The APPC team in COM3360 needs it.
 > Please can you send me the documentation
 > so taht I can guide them if needed.

Here's the current interface (not yet checked in).  Let me know if you 
have any suggestions for improvements or additions.  Not included here 
is the extra interface that the code generator uses to generate the
nodeset checking and masking code; I'm still thinking about how best

Bill will interpret the traversal graphs instead of generating code for
them. I guess that the nodeset checking and masking code would also
be useful for interpretation? If so, it should be exported so that
Bill can use it.

to export that information.  But what is here is enough information if 
all you're interested in is the subgraph.

  // Step 1: define classes implementing the interfaces NameI, which is
  // empty (it's only used as keys in a hashtable), and StrategyGraphI:

  /** A directed graph whose vertices are NameI objects and whose
      edges are uniquely labeled with consecutive ints starting from 0.
      Also associated with each edge is a constraint (i.e. a boolean
      predicate) on class graph edges.  Additionally, the graph has
      a set of source vertices and a set of target vertices. */
  StrategyGraphI {
    /** An Enumeration of vertices (NameI objects) in the strategy graph. */
    public Enumeration getVertices();

    /** An Enumeration of source vertices (NameI objects),
	or null if the strategy is "from *". */
    public Enumeration getSources();

    /** An Enumeration of target vertices (NameI objects),
	or null if the strategy is "to *". */
    public Enumeration getTargets();

    /** The number of edges in the strategy graph. */
    public int numEdges();

    /** A Vector of Integers of the incoming edges to vertex c. */
    public Vector getIncomingIndices(NameI c);

    /** A Vector of Integers of the outgoing edges from vertex c. */
    public Vector getOutgoingIndices(NameI c);

    /** Does the edge meet the constraint on the ith strategy edge,
	given the name map?  The name map is a total map from NameI to
	NameI, both class names and part names. */
    public boolean meetsConstraint(int i, Edge edge, Dictionary nameMap);
  }

  // Step 2: construct a ClassGraph object and add an edge for each edge
  // in the class graph using addConstructionEdge, addAlternationEdge,
  // and addInheritanceEdge.  This object can be reused for multiple
  // traversal graph computations (with different strategy graphs).

  ClassGraph {
    /** Add a construction edge from source to dest named name. */
    public void addConstructionEdge(NameI source, NameI name, NameI dest);

    /** Add an alternation edge from source to dest. */
    public void addAlternationEdge(NameI source, NameI dest);

    /** Add an inheritance edge from source to dest. */
    public void addInheritanceEdge(NameI source, NameI dest);
  }

  // Step 3: supply a strategy graph and name map to produce a traversal graph.

  ClassGraph {
    /** Compute the traversal graph corresponding to the strategy graph
	sg with the given nameMap.  A null nameMap means the identity
	function. */
    public TraversalGraph computeTraversalGraph(StrategyGraphI sg,
						Dictionary nameMap);
  }

  // Step 4: query (or iterate over) the traversal graph to determine
  // what nodes and edges in the class graph are in the traversal.

  TraversalGraph {
    /** Is the named vertex in the traversal graph? */
    public boolean hasVertex(NameI name);

    /** An enumeration of the vertices in the traversal graph. */
    public Enumeration vertices();

    /** Is the named construction edge in the traversal graph? */
    public boolean hasConstructionEdge(NameI source, NameI name, NameI dest);

    /** Is the named alternation edge in the traversal graph? */
    public boolean hasAlternationEdge(NameI source, NameI dest);

    /** Is the named inheritance edge in the traversal graph? */
    public boolean hasInheritanceEdge(NameI source, NameI dest);

    /** An enumeration of the edges in the traversal graph. */
    public Enumeration edges();
  }

--Doug

From dougo@ccs.neu.edu Tue Nov 10 21:20:50 1998
From: Doug Orleans <dougo@ccs.neu.edu>
Date: Tue, 10 Nov 1998 21:20:48 -0500 (EST)
To: Karl Lieberherr <lieber@ccs.neu.edu>
Cc: vaultgus@ccs.neu.edu
Subject: Re: arrays

Karl Lieberherr writes:
 > what is the best way to use Javba arrays in Demeter/Java?
 > 
 > Can you make an array directly a data member?
 > Or do you put them into a separate class?

Neither.  You'll have to use arrays only in the behavior file, e.g.

    Foo {
      (@ Object a[]; @)
    }

Otherwise, use repetition classes, or Vector/Hashtable/BitSet.

 > >One of the functions, specifically Sobel Edge detection, required that I
 > >keep the intensity of the pixels stored in an array so I could easily access
 > >a pixel's neighbors. I haven't seen anything like an array in any of the
 > >Demeter dictionaries. How would something like that be implemented? It would
 > >seem to violate the structure-shy property of Demeter/Java.

Right, you can only traverse a collection using a repetition class,
which for now must be a linked list.  This has been on the todo list
for a long time.

--Doug