[antlr-interest] OO design question

[Greg Vaughn]

Terence Parr wrote:
> My specific question at the moment relates to what you might call 
> aspect-oriented programming vs oo programming.  Consider the data 
> structure representing your grammar (i.e., the graph).  It's very neatly 
> organized as a set of GrammarElement subclasses that include subrules 
> and atoms like token-refs.  Now, how do you perform analysis on this 
> graph?  Conceptually you would like to keep the analyzer separate (so 
> somebody could build a different one and for good programming practice 
> reasons).  I would call this an aspect not an object encapsulation 
> idea.  Anyway, currently I have added a method to each GrammarElement 
> called lookahead() or some such that is supposed to compute lookahead 
> for that type of element.  Works great except for the fact that now my 
> analyzer is not a big chunk (an aspect of ANTLR) it is completely 
> interwined with the graph data structure.  The reason of course is that 
> it is really nice to ask a node for it's lookahead.  In order to 
> separate out the analyzer, you'd have ask the analyzer to look at a 
> node: Analyzer.lookahead(GrammarElement).  But, you'd lose polymorphism 
> and have to have a switch in lookahead that asked what kind of node it 
> was.  Ick.
> 
> So!  How do you get a good separable chunk called an Analyzer without 
> making the implementation fully of crappy switch-statements?  I.e., how 
> do I use aspect programming w/o losing the polymorphism convenience?!  
> Anybody wanna lend me some smarts?

I've been a lurker on this list for a while now and still haven't had 
the time to dig into ANTLR like I've wanted, but I have done a few 
things with AspectJ, so I'll put in my 2 cents.

This sounds like a prime candidate for aspects. With an Analyzer aspect, 
you could change the code in all the lookahead() methods of 
GrammarElement subclasses at "weave" time. You could even make the 
method abstract and let the aspect create concrete subclasses that 
implement lookahead() however the Analyzer needs it. You may end up with 
a nasty switch in the aspect, but the price is only paid at "weave" 
time. Alternatively you could specify different joinpoints for each of 
the subclasses to treat them separately to avoid the switch.

Greg Vaughn
Delphi Consultants, LLC
gvaughn at delphis.com


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/