(My initial message at the end)

>From dougo@ccs.neu.edu Mon Sep  1 17:25:05 1997
>Cc: boaz@ccs.neu.edu
>Subject: Re: example in Demeter/Java
>
>Karl Lieberherr writes:
> > Next we define a traversal/visitor combination {\tt t}, 
> > called traversal {\tt t}, 
>
>I call this a "traversal method", which is a strategy combined with a
>list of parameter types (visitor classes).

I have adopted your terminology and borrowed the above sentence.
>
> > We may specialize traversal {\tt t} by 
> > creating methods using subclasses of {\tt CountingVisitor}.
>
>This statement doesn't make much sense, and seems extraneous to the
>discussion anyway.  
>

Ok.

>
> > Finally, we define a method {\tt CountCertainEs} for class {\tt A} 
> > which defines
> > with which subclass of {\tt CountingVisitor} we want to do the work.
>
>I call this an "adaptive method".
>

Have adopted your terminology.

> > To summarize the adaptive programming approach used above, called
> > the strategy/visitor style, we note
> > that behavior is expressed in terms of strategies and
> > visitors. Strategies and visitors are combined in two steps:
> > 1. First a family of strategy/visitor combinations, 
> > called traversals (overloading the term),
> > is defined. 2. A specific member of this family is selected by specifying
> > which specific visitor subclass to use.
>
>This notion of a "family" is kind of confusing-- a traversal method is

I agree; removed familybut kept two step approach

>exactly that, a method that defines a traversal (using a strategy).
>Also, as long as you use "traversal strategy" everywhere to mean an
>abstract path directive (i.e. not attached to a particular class
>structure or visitor class), and "traversal method" to mean a method
>attached to a class that traverses an object graph, I don't think
>there's any overloading.  However, it's still a little confusing to

Reused some of the above phrases.

>bring this up-- again, maybe using the "inline" style of adaptive
>methods directly would be clearer for the discussion?  The paper is
>about strategies, not the ability to re-use visitors (as opposed to
>your keynote speech, which is about both).  E.g. simply:
>
>    \begin{verbatim}
>    A{
>      int CountCertainEs() do S {
>	before E (@ return_val++; @)
>      }
>    }
>    \end{verbatim}
>
This is indeed very elegant but we need to have our customers in mind.
There are at least two kinds:

1. The Demeter/Java users or implementers
2. The Design Pattern miners who want to use unextended Java.

At least initially, group 2 is larger and if we explain in terms
of visitors, it is easier to see how the design style you designed
and implemented in Demeter/Java can be adopted in a traditional environment.

>
>Hm, now that I look at it, I wonder if "use" would be a better keyword
>than "do" for referring to named strategies?  Or "using"?  Hm.
>

I think that "do" is pretty good since we also might have:

join( do S1, do S2)

use or using would be a little longer.
>--Doug
>

Thank you for your detailed feedback. The revision is in 
/proj/asl/lieber/papers/new-state-passing-compiler/graph-strategies/examples/app-code.tex

and will be in the final paper.

-- Karl
==========================================
====================
Hi Doug:

below is a fragment of the paper with Boaz describing the
DJ implementation of the paper example.

Do you agree with it?

-- Karl
==============================


Goes in appendix B.

We show how to program the example of Fig. 1 in Demeter/Java
\cite{cse:preventive}.
We need to express the strategy and the class graph in Demeter/Java
and we show how to write a program which not only traverses a
given {\tt A}-object according to the given strategy
but which actually counts the number of {\tt E}-objects found
during the traversal.

The strategy with default name map and with constraint map is
expressed by a strategy definition {\tt S}.

\begin{verbatim}

strategy 
S = { A -> C bypassing -> A,m,C
	    C -> E
       A -> D
            D -> E bypassing A }.

\end{verbatim} 

The notation for strategy graphs is an edge list format where each
edge may have constraints associated with it. Since we use the default
name map, each strategy graph node label represents a class in the class
graph. The notation makes the assumption that identical node labels
mean identical nodes. Therefore, S represents exactly the strategy
graph in Fig. 1(B).

The class graph is annotated with some syntactic sugar to make it
an LL(1) grammar which is given to the Java Compiler Compiler to 
create an object for a given input sentence. We express the grammar
as follows \cite{APBook}:

\begin{verbatim}
A = <l>B [<m>C "end"] <p> F .
B = <o>D .
C = "c" <n>A .
F = <q>E .
D : C | E . 
E = "e" . 
\end{verbatim} 

We will not explain this EBNF-style grammar notation in detail. 
The grammar is only a textual
expression of the class graph in Fig. 1(A). There is one detail which 
is important: The class graph in
Figure 1(A) contains a cycle from {\tt A} to {\tt C} and back to {\tt A}.
This means that there are no tree objects of class {\tt A}. In order
to allow tree objects, the edge from {\tt A} to {\tt C} is optional.
Figure 1 and Figure 2 don't address this issue.

To write the program which counts the number of {\tt E}-objects contained
in an {\tt A}-object, we first define a visitor class:

\begin{verbatim}
CountingVisitor {
  int r;
  init (@ r = 0; @)
  before E (@ r++; @)
  return int (@ r; @)
}
\end{verbatim} 

This visitor class is encapsulating the counting behavior, including
how to initialize (the init method)
and what to return (the return method) after the traversal is complete.

Next we define a traversal/visitor combination {\tt t}, 
called traversal {\tt t}, 
using the strategy {\tt S} we defined earlier and the {\tt CountingVisitor}
defined above. We may specialize traversal {\tt t} by 
creating methods using subclasses of {\tt CountingVisitor}.
Finally, we define a method {\tt CountCertainEs} for class {\tt A} 
which defines
with which subclass of {\tt CountingVisitor} we want to do the work.
In this case we use {\tt CountingVisitor} itself.

\begin{verbatim}
A{
  traversal t(CountingVisitor v) { do S; }
  int CountCertainEs() = t(CountingVisitor);
}
\end{verbatim}

We call CountCertainEs in class Main as follows.

\begin{verbatim}
      Example a = Example.parse(System.in);
      int result = a.CountCertainEs(); 
\end{verbatim} 

On input "e e", the following object will be created:

\begin{verbatim}
<a> : A  (
  <l> : B  (
    <o> : D  (
      <e> : E  ( ) ) )
  <p> : F  (
    <q> : E  ( ) ) )
\end{verbatim}

The result is 1.

To summarize the adaptive programming approach used above, called
the strategy/visitor style, we note
that behavior is expressed in terms of strategies and
visitors. Strategies and visitors are combined in two steps:
1. First a family of strategy/visitor combinations, 
called traversals (overloading the term),
is defined. 2. A specific member of this family is selected by specifying
which specific visitor subclass to use.

The strategy/visitor style is a good approach 
to express behavior since both strategies
and visitors are reusable and the resulting programs can 
be more easily evolved by changing strategies or visitors or class graphs.
The coupling between strategies and visitors is loose, much looser
than in the tangled mess of the visitor design pattern described in 
\cite{Gamma} where the class graph information is spread all over.