Digging through the AST Hierarchy

After having a few meetings with Dennis this week regarding the AST, I started to realize that my conception of the entire AST package may have been put together in a very incomplete way. Specifically, my knowledge of the classes and hierarchy was developed on a very "need to know" situational basis: I would conceptualize a test that I wanted to write, and then search for the AST components that would be necessary to understand for that test.

As a result, my knowledge of how the AST works together is relatively fragmented. What I determined I need to get is a better overview of how the system functions and fits together as a whole in order to give myself the maximum ability to construct code tests. In order to accomplish this, I am currently constructing (with paper & pencil) a diagram of all the classes in the AST package, starting with the top-most class ("AbstractNode") and moving down through the full class hierarchy.

On the diagram, I'm including arrows to show inheritence, as well as detailing the relevant class member variable and functions. Although I haven't given a formal reasoning for which methods I consider "relevant," I have mostly been considering any public accessor methods as potentially relevant. One of the especially useful features of this visual representation that I have noticed is that many of these accessor methods have return types that are also types in the AST package, and, by having information about all these classes instantly viewable, the class relationships become much clearer.

Already, I have been discovering useful functions that I wish I had known about before. As I continue diagramming, I expect to only be finding more of these.