Object-Oriented Programming

OOP Class Notes for 09/18/13

Version Control Systems and Build System

• Version Control Systems (VCS)
  • VCS is a repository that keeps files and history of files.
  • Being able to efficiently down track revision history of your source codes is essential when there are multiple collaboraters on a project.
  • VCS can also be used to have backups for your source codes and data. Be paranoid.
  • VCS does NOT solve every problem:
    1. Some problems can rise from multiple people working simultaneously.
    2. Determining the authoritative version can be problamatic.
  • There are two types of VCS.
    • Client-server (e.g. CVS and Subversion)
    • Distributed (e.g. git)
  • We will be using git. There is a learning curve, but it is extremely important to learn how to use version control systems efficiently.
• Build System aka "make"
  • We use "make" to simplify many standard procedures.
  • "make" will compile any updated source, and "make check-java" will run xtc's Java unit tests.

Introduction to xtc

• xtc
  • The xtc (eXTensible Compiler) project is exploring novel programming languages and tools to improve the expressiveness, safety, and efficiency of complex systems. (http://cs.nyu.edu/rgrimm/xtc/)
  • In this class xtc will provide lots of functionalities that can faciliate our projects. For example, xtc already has a method that creates a complete Java AST given an input source file in .java.
  • The trade-off of using xtc: xtc is indeed an extensive library that already has implemented lots of functionalities we need for the Translator Project, but the issue is that xtc is NOT simple to understand. By trying to understand and use certain implementations of xtc for the project, you might spend more time by wrapping your head around the xtc implementation than implementing your own tool from the scratch.
  • For example, consider the following fact: xtc has the construction of Java AST and the C AST builtin which we can utilize in our project; however, it does NOT support C++ AST. There could be a discussion on ways to implement the C++ AST: Should we simply extend the C AST that xtc provides or implement the C++ AST by implementing from the scratch, modeling our implenmentation on the Java AST that xtc provides?
  • All in all the groups should spend considerable amount of time discussing the "xtc tradeoff," because it is an integral part of designing the project architecture.
  • To get the taste of xtc, we coded a baby Translator that works closely with the Java AST of xtc. We begin the process by extending the xtc.util.Tool class to start our Translator class.
  • The following is the code implemented in the class:

  public void process(Node node) {
  
    new Vistor() {
      // to visit a node in given file we write within the process method
      // we are visiting nodes of different types. compilation unit vs. method declaration vs. others
  
      public void visitCompliationUnit(GNode n) { 
        // we want to visit the entire tree. We should recurse through all children how do we do that?
        // visit(n) does the trick. 
        visit(n);
        runtime.console().p("Number of methods: ").p(count).pln().flush();
      }
  
      public void visitMethodDeclaration(GNode n) {
        visit(n); //to visit the methods inside the methods
        count++;
        // if you want the name of the method. It's the 4th child so that you would do n.getString(3) on a GNode n
      } 
  
      public void visit(Node n) {
        // dispatch children
      }
    }.dispatch(node);
  }
  
  			

  • We override the getName, getCopy, init, prepare, locate, parse, and process methods of our Translator class. Furthermore, in the init method we call init on the super class, and then declare our command line arguments.
    • printJavaAST prints the Java AST that xtc constructs.
    • countMethods counts all the Java methods.
  • The key class to note in this code is the Visitor class. The Visitor class in xtc allows you to traverse through the Java AST. The method call visit(n) will recursively visit the children of node n recursively. Notice that the Visitor class inside the process method is an example of an anonymous class where you modify the class while instanticating an object of an already existing class.
  • Notice the method names inside our anonymous Visitor class. The choice of the method names, such as "visitMethodDeclaration" isn't simply an outcome of the "extremely verbose" naming convention we agreed on. Naming in this case is a more subtle issue of using xtc to facilitate our code, because when we write a method name by appending the word "visit" in front of a common node name in the Java AST, the implementation of Visitor's dispatch invokes that method for us, that way allowing us to traverse through the Java AST. (Try experiementing on your own by changing the names of the methods) The point is that there are many subtle things going on that is related to xtc even in this short piece of code we wrote.
  • The following explanations are the few details on what's going on in this code and how to properly set up the build system and sort out the package issues.
  • The locate method locates the file name that was passed in from the command line, and checks that its length is not larger than the max value of a Java Integer.
  • The parse method creates a JavaFiveParser object from xtc and parses the content of the file and then returns the AST that was generated.
  • The process method processes the AST that was generated by the parse method, and then depending on what command line arguments were passed, will print the Java AST or, visit the nodes and count methods in this example.
    • the "-printJavaAST" argument calls xtc's runtime.console() method and formats the AST, prints a new line, and then flushes the output buffer.
    • the "-countMethods" argument will declare an anoynmous Visitor class (from xtc) with methods for visiting nodes.
      • Each time visit is called, we use for loop to iterate over all the children of the node and for each child which is a node call dispatch which dispatches a visitor on that node.
      • If we are at a MethodDeclaration, we increment visit all the children and then increment the count.
      • the first time the visitor is dispatched, it is on the root node of the AST which is the CompilationUnit object.
  • In order to compile our file, we copied a Makefile from one of the other xtc packages, and put it in our oop package directory. Then we gave it a name in the makefile's PACKAGE and PACKAGE_LOC variables, and declared the source files in the SOURCE variable. Which was only Translator.java. Then "make" compiled our source.
  • To run the Translator, you run: "java xtc.oop.Translator -printJavaAST Translator.java" and that will print the AST for the Translator.java file.
  • The -countMethods argument will count the number of methods that were declared in the source file.