Re: More Visitors

["Etienne Gagnon" <egagnon@sprynet.com>]

Hi Nick,

>What does caseShape do?  The most useful thing would be to do nothing
>with the current node, but somehow iterate over the children nodes.
>This is where you need a second visitor (which I've called the
>HelperVisitor).  It'd be a lot like DepthFirstAdaptor, but it'd take
>an additional paramater (the first visitor), and instead of applying
>itself to the children, it would apply the first visitor.


You have pointed the reason I had not included methods for visiting
"productions" in addition to "alternatives": What do you do with an abstract
class that has no children?

The problem is that if you want to visit the children, you will have to
determine the "alternative" first and use a type cast (or an additional
switch).

But, if you and other people have a need for it, then it is possible to
implement using a slightly different approach than yours. (You forgot that
the "apply()" method is hard coded for a specific "switch", so your approach
is difficult to implement).

Here's how:
I could make SableCC generate three additional classes in the analysis
package. (It would be nice if somebody could suggest better class names).
Here's the first one:

class DerivedAnalysisAdapter extends AnalysisAdapter
{
  void caseAAlt1Prod(AAlt1Prod node)
  { casePProd(node);}
  void caseAAlt2Prod(AAlt1Prod node)
  { casePProd(node);}
  void casePProd(PProd node)
  { defaultCase(node); }
  void defaultCase(Node node)
  {}
}

The intresting behavior of this "switch" is that it lets you switch on
productions, not only alternatives. Furthermore, if you specify some action
for an alternative, it won't execute the production action [unless you
sepcifically call casePProd()].

The two other classes would be derived from DepthFirstAdapter and
ReverseDepthFirstAdapter. They would implement inPProd() and outPProd().

>So what do people think?  Could something like this be added to SableCC?


The question remains: Is there a need for this?

Etienne