Object-Oriented Programming

OOP Class Notes for 9/19/13

Version Control with Git

• We will be using Git for verision control.
• Key concepts:
• Local repository: a copy of the version graph maintained locally on your machine (in a .git directory).
• Remote repository: a copy of the version graph maintained on some remote machine (e.g. a git hosting service).
• Working directory: the version of the files in the repository which you have checked out to work on. The working directory corresponds to one node in the version graph of your local machine (e.g. the latest version in the master branch).
• Staging area (also called index): the changes in the working directory that are scheduled for the next commit to the local repository.
• Key commands:
• init: create a new local repository in the current directory
• checkout: set the working directory to some node in the version graph.
• status: see which files belong to the working directory / are in the staging area
• add: add a file or changes made in a file to the staging area.
• commit: commit the staging area to the local repository (this creates a new node in the version graph)
• remote add: associate a remote repository with the local repository.
• clone: create a local repository from a remote repository
• push: update the remote repository by merging all pending changes in the local repository
• pull: update the local repository by merging all pending changes in the remote repository.
• You may use any git hosting service for setting up the remote repository, as long as the service supports private repositories. One possibility is GitLab Cloud.

Unit Testing with JUnit

• JUnit is a unit testing framework for Java. In the OO context, unit testing refers to the testing of the functionality provided by an individual class.
• Work flow for unit testing:
  • For each class C that you write, write an additional test class CTest that tests C's functionality.
  • Use JUnit to automate the execution of the unit tests and the generation of test reports.
  • Integrate unit testing into your development process (e.g. always run unit tests before you push code changes to the remote repository, never push changes that make some unit test fail).

Q: When to commit/push?

• When NOT to commit:
  • Did not compile code
  • Broken code (breaks build for others)
  • Takeaway: commit, as long as stuff builds and runs without errors.

Q: What is scope?

• Scope is the area of visibility of identifiers such as variables, fields, methods, etc. For example, all the fields and methods of a class are visible within the class. The scope of a method is within the method.
• One distinguishes between static (or lexical) and dynamic scopes. In a statically scoped language, the visibility of a variable is fully determined by the program source code. In a dynamically scoped language, the visibility of variables is determined by the runtime behavior of the program, e.g., the order in which functions are called. Most programming languages are statically scoped.

Q: Structure of xtc? Visitor class?

• Important:
  • Runtime.java (in xtc.util)
  • Tree.java (in xtc.tree)
    • GNode is used for dynamic trees
  • Tool.java (in xtc.util)
  • SymbolTable.java (in xtc.util)
  • Parser package (xtc.parser)
  • Lang package (CPrinter.java)
    • JavaFiveParser.java (in xtc.lang)
    • FactoryFactory.java (in xtc.lang)
• Visitor class (in xtc.tree):
  • The key method of the visitor class is "dispatch". The contract is as follows:
  1. if the dispatched node is a dynamically typed GNode with name NAME then find the method "visitNAME" and call it with the dispatched node.
  2. if the dispatched node is a statically typed tree node (i.e., a node of some class C that extends Node) then find the "visit" method that takes a C node and call it with the dispatched node.
  • When we extended the Visitor class in the "process" method of our baby translator, we provided a "visit" method that takes a Node object as argument. This has the following effect:
  • Suppose we traverse a Java AST returned by the xtc Java parser (this AST consists of GNode objects). Suppose further that during the traversal we dispatch a node n with name NAME, and suppose the case 1 above does not work because we did not provide a visitNAME method (e.g. NAME could be "ClassDeclaration"). Then case 2 still applies because the class GNode extends Node. That is, n is also a Node object and we can always call "visit" with n as argument. This is what "dispatch" in the Visitor class implements.

Q: Organizing code with xtc? Make?

• Two ways:
  1. Jar file - binary release allows for flexibility in how you organize your directories and build system
  2. Update xtc’s directory structure
     • Copy and edit a package make file, such as src/xtc/oop/Makefile
     • Update PACKAGES in the global make file with your package
     • Tip: . setup.sh sets environment variables in the current shell versus in another.

Q: Structure of AST? Typing? (three ways of figuring it out)

• To get the structure of the AST, java xtc.oop.Translator -printJavaAST File.java prints the program as a tree.
• Three ways:
  1. Feed toy translator tool in the last class inputs and see what the input looks like.
  2. Look at grammar (in src/xtc/lang/JavaCore.java) and it will state the declarations
  3. in src/xtc/lang: java xtc.parser.Rats -ast -variant -in ../.. JavaFive.rats prints declarations as ML data types.

Q: What’s hard?

• The process:

  1. Read in (“parse” into an Abstract Syntax Tree).
  2. Analyze. Have to run it, read in dependencies. Then analyze those depedencies.
  3. Determine internal data representations.
  4. Define own C++ AST and translate.
  5. Pretty print C++ code, so you can debug.

• Assume memory is infinite, but memory is not infinite for the final project.

• Inheritance and virtual methods are the hardest part, since you must NOT use them in generated C++.