From lieber@ccs.neu.edu Sun Aug  3 19:08:55 1997
To: dougo@ccs.neu.edu, lieber@ccs.neu.edu
Subject: Re: visualizing traversal graphs
Cc: dem@ccs.neu.edu, kedar@ccs.neu.edu

Hi Doug:

>From dougo@ccs.neu.edu Fri Aug  1 17:11:03 1997
>From: Doug Orleans <dougo@ccs.neu.edu>
>To: Karl Lieberherr <lieber@ccs.neu.edu>
>Cc: kedar@ccs.neu.edu, dem@ccs.neu.edu
>Subject: Re: visualizing traversal graphs
>
>Karl Lieberherr writes:
> > I think a node name in a traversal graph should have the following form:
> > X$m$n, where X is a class name and m and n are node names in a strategy
> > with an optional class name seperated by __.
> > $ plays the role of a separator. It is a legal letter in Java.
>
>According to the language spec:
>
>  The $ character should be used only in mechanically generated Java code.

Thank you; I did not know about this.
In this case the node names of traversal graphs should have
a more complex structure to reflect their "origins".

>
>So I don't think the user should be able (or be forced to) specify an
>identifier containing a $.  For example, inner classes are translated
>to regular classes with the name OuterClass$InnerClass, but the user
>can (should) only refer to the inner class inside the scope of the
>outer class.
>
> > Example: X$n1__A$n2__B
> > is a node in a traversal graph which corresponds to class X in
> > the class graph and which is "caused" by the strategy edge
> > from node n1 to node n2 in the strategy graph. The __ with class name
> > is optional and indicates how the strategy graph is mapped into the class
> > graph. In the above example, n1 is mapped to A and n2 is mapped to B.
> > 
> > If the default mapping is used (each node in the class graph
> > appears at most once in the strategy graph, i.e., the name map is
> > one-to-one) then we can delete the __ part: X$A$B.
> > This means that the traversal of the X-object is caused by the strategy
> > edge from A to B.
> > 
> > Regarding the visitors, I suggest that we use a strategies argument
> > for every traversal. The visitors can query the token set with:
> > 
> > if (strategies.active({"A$B","A$C"})) { ... }
> > or
> > if (strategies.active({"x__A$y__B","r__A$s__C"})) { ... }
> > 
> > The argument is an array of type String[].
>
>I think I would prefer some sort of syntax at the Demeter level,
>rather than making the user write arbitrary Java to query the token
>set.  For example:
>
>    Company {
>      int countEmpInDept() 
>	via Dept to Emp
>	// expands to the strategy graph: { Company -> Dept, Dept -> Emp }
>      {
>	(@ int count = 0; @)
>	before Emp : Dept -> Emp (@
>	  // Count only Emp objects in the "Dept -> Emp" edge of the
>	  // strategy, i.e. inside Dept objects.
>	  count++;
>	@)
>	return (@ count @)
>      }
>    }
>
>Any better ideas for syntax?

That is a very elegant approach for this kind of situation.
I also don't like the explicit conditionals of my proposal.
Here is an evaluation:

More Demeter Syntax:
Advantages:
No conditionals. 

Disadvantages:
Can we predict all possible useful uses of the token set?
How complete is syntax?

Token set used in visitors:
Advantages:
High flexibility. Token set can be used in many different ways.
No new syntax to learn (besides referring to traversal graph).

Disadvantages:
Does not look so good. Should avoid conditionals when possible.
>

A good strategy seems to be to first use the token set solution
and observe users how they use it and then design Demeter 
syntax based on that? The token set is passed as an argument anyway.

>--Doug
>

-- Karl