Doug:

thank you for reviving the multi-sourced edges. I like them too.
They have the advantage of allowing us to write 1 method with n arguments
instead of n methods with different ordering of the arguments.

Geoff:

Please can you add the muti-sourced edges to your example
for derived edges. The rule will be that if a multi-sourced
edge is traversed then the arguments must be in the visitor
(or arguments of an adaptive method).

The plan is that you add multi-sourced edges to your derived
edge implementation.

I don't understand Doug's remark at the end of the message
about collecting too much information in a visitor.
The programmer descides which object to put into the visitor.

-- Karl

>From dougo@ccs.neu.edu Tue Aug  5 16:23:52 1997
>From: Doug Orleans <dougo@ccs.neu.edu>
>To: Karl Lieberherr <lieber@ccs.neu.edu>
>Cc: ghulten@ccs.neu.edu, dem@ccs.neu.edu
>Subject: Re: visitors to the rescue
>
>Karl Lieberherr writes:
> > here is another idea which we could use: I refer to the class
> > dictionary for graphs on page 213 and the program on page 214
> > of my book. (Note: I switched the arguments for the find method
> > to make it traversal ready.)
> > 
> > Let's assume that we want 
> > 
> > All Adjacency-objects of the outgoing edges from some Adjacency-object.
> > 
> > We would like to write one strategy:
> > 
> > from Adjacency through -> *,neighbors,* to Adjacency
> > 
> > A traversal might be:
> > 
> > Adjacency Vertex_List Vertex_NonEmpty Vertex Adjacency 
> >                                             ^ derived egde: find
> > 
> > The last edge is a 
> > derived edge: -> Vertex,find,Adjacency wich requires Graph g as argument.
> > (It needs to search through the list)
>
>I like the idea of multi-sourced edges, from Greg Sullivan's tech
>report (95-01, available in 107 CN).  With that approach, the derived
>edge would be written:
>
>  Greg's notation:
>    find : ( Vertex x Graph ) -> Adjacency // "x" means "cross product"
>
>  Demeter/Java notation (proposed):
>    -> <Vertex,Graph>, find, Adjacency
>
>It would be drawn as arrows from Vertex and Graph into a "join node"
>(a dot), and an arrow from the join node to Adjacency.
>(Unfortunately, I don't see how to write this edge in the class
>dictionary form, i.e. a context-free grammar...)  Then you would
>write the strategy as:
>
>    from Adjacency, Graph // note: different from the set { Adjacency, Graph }
>     through -> *,neighbors,*
>    to Adjacency
>
>The user of the adaptive method would provide two objects, an
>Adjacency and a Graph, and the traversal would use the Graph object
>when it needs to traverse the "find" edge.  (See page 16 of Greg's
>tech report for an explanation of the "prepared set" algorithm.)
>
>This is how I imagine this would be written as an adaptive method:
>
>    Adjacency {
>	void allNeighbors(Graph g)
>	    through -> *,neighbors,*
>	{
>	    before Adjacency (@ /* do something */ @)
>	}
>    }
>
>The arguments to the method are considered to be additional sources of
>the traversal (besides the receiver object).  What's interesting is
>that the way I currently implement adaptive methods, the Graph object
>becomes a part of the generated visitor, and we end up with exactly
>what Karl suggested:
>
> > When a derived edge is traversed which requires some arguments,
> > they are taken from the visitors.
>
>This isn't so simple when the join nodes are further down in the class
>graph, however.  Consider this extension to the class graph in question:
>
>    Graphs = ForwardGraph ReversedGraph.
>    ForwardGraph = Graph.
>    ReversedGraph = Graph.
>    // rest is the same
>
>Now say the user wants to write this adaptive method:
>
>    Adjacency {
>	void allNeighborsInForwardGraph(Graphs g)
>	    through { -> *,neighbors,*
>		      ForwardGraph }
>	{ ... }
>    }
>
>The traversal has to go from Graphs -> ForwardGraph -> Graph before it
>can deliver the Graph object to the multi-sourced "find" edge.  Should
>all these objects be stored on the visitor?  This seems to imply that
>every object we come across during the traversal needs to be stored in
>the visitor, which seems like overkill, expecially if they're all
>statically defined as parts (as opposed to keeping the objects in a
>Hashtable).  Nevertheless, this approach seems a lot more elegant to
>me, but it will be rather tricky to implement correctly.
>
>--Doug
>