Hi Crista:

a thought provoking message. Boaz just revised our paper
on traversal graphs and I put a new version into:

ftp://ftp.ccs.neu.edu/pub/people/lieber/strategies.ps

This one now explains traversals again in terms of class graphs.

>From lopes@parc.xerox.com Tue Aug  5 16:48:06 1997
>From: Cristina Lopes <lopes@parc.xerox.com>
>To: dem@ccs.neu.edu
>Subject: traversals
>
>
>And since I'm at it, here goes a suggestion for you to think about. 
>
>Why do you need to compute traversal _graphs_ at all?
>
>Reason for this question: computing traversal _graphs_ establishes a
>nasty dependency between traversal directives and the class graph. 
>That is, if you change the class graph, you need to recompute the
>traversal graphs. (and consequently the Traversal Objects)
>
>Alternative: don't compute traversal graphs. Translate traversal
>directives into a set of classes_with_missing_parts. The actual
>run-time traversals simply check if they are allowed to go through the
>parts or not. (See implementation of marshaling methods in Ridl)
>
>I suspect the reason why you *need* traversal graphs is the nature of
>your traversal language, in particular the "to" and the "via" and the
>"through" clauses, which, according to the semantics they have now,
>need global information about the graph. However, if you assume
>_class_ graphs (as opposed to object graphs) these clauses can be
>translated into "bypassing" by a pre-processor (this is a challenging
>statement!, but it's true :).

I think that for 90% of the combinations of strategies and class graphs
occurring in practice you are right: 
we could translate the strategy into a new one
which has only one strategy edge and bypassings.

But there are many cases which could not be translated this way.
For example, look at the example on page 18 of
ftp://ftp.ccs.neu.edu/pub/people/lieber/strategies.ps

Maybe you are right that we should consider such a translation when the
situation allows. In the case of consistency between class graph
and strategy, we can compute the propagation graph which will tell
us which edges we should bypass.

>
>This is, again, my strong opinion about what kinds of things you
>should be able to say with a traversal language. For me, the subject
>matter of such language should be the _classes_, not the objects. This
>is a language design issue that has never been explained to my
>satisfaction in Demeter, and which I have attempted to address in the
>Reflection'96 paper (and which has been solved in Ridl). I always felt
>that explaining the meaning of traversals in terms of object graphs is
>extremelly confusing, because when you specify the directives you only
>have handles for the classes, not the objects. And this semantic
>confusion has its consequences on the implementation: if you assume
>object graphs, you need more than bypassing, and you need to compute
>traversal graphs; whereas if you stick to class graphs, you can do it
>only with localized bypassings, and you will be able to implement
>traversals in separate from the particular class graphs.
>
>Much more could be said, but this should be enough to start the
>discussion among you.
>
>-Crista
>

I don't understand the link between bypassing/through and object graphs.
We have lived with bypassing only (without through or via)
for a while in Demeter/Java.
A positive way to express traversals using strategies is
a welcome change.

Do you propose a generic traversal which goes everywhere
but which checks each edge whether it is in the bypassing set?
Your Ridl function traversal_write_body seems to do something like this.

-- Karl