String (and Integers)
Interpreters, Iteration 4

User Story

"This is a string"

"So is this!!!"

You need to do this in addition to interpreting an integer.

The procedural solution is a bit tricky because input strings will be written like "hello", complete with the double quotes. The ASTs that you get back from the parser will still have the double quotes, and you'll have to handle them. (The object-oriented solution uses the TIR builder, a step beyond the parser, and the TIR builder takes off the double quotes for you.)

The object-oriented solution is easy. You'll change one word in your existing code (and write a couple of tests). Don't worry: the object-oriented solution will be more interesting in the next iteration.

Procedural Solution

Your procedural solution receives an AST, and it's supposed to return a String result. You can easily build STRING ASTs:

This will allow you to easily create assertions for STRING ASTs.

You can't written any assertions yet, so the code should still green bar.

Here's an assertion:

assertEquals("abc123", myInterpreter.interpret(createStringAST("\"abc123\"")));

Note the double quotes around the actual string. Your interpreter has to strip these double quotes away.

You should get a complaint about the double quotes. What you already have for the interpret(Tree) method should return something for a STRING, except for those double quotes.

So turn your attention to ProceduralInterpreter#interpret(Tree). Just returning the text of the AST is correct for an INTEGER, and you do not want to lose this. However, you have to do something different for a STRING.

You need to make a decision based on the type of the AST. With a procedural approach, the right way to do this is to get the AST's type from the AST itself. Not too surprisingly, ANTLR gives us a getType() method for Trees. This returns an int which can be compared against constants that ANTLR defined in the grammar: HobbesParser.INTEGER and HobbesParser.STRING.

So I could write code like this if I just needed some feedback:

switch (tree.getType()) {
case HobbesParser.INTEGER:
  return "this is an integer";
case HobbesParser.STRING:
  return "this is a string";
default:
  throw new IllegalArgumentException(tree.getType() + " is unrecognized");
}

Based on the type of the AST (in tree, of type Tree), I decide which feedback message to return. If I need to do more work for one or the other, I just add more code for that case. The throw clause is helpful for debugging purposes. (Hopefully, you never need it, but if it ever gets triggered, it can save you a lot of time debugging.)

You should get the thrown exception causing the red bar. (The old integer tests should still pass!) If you look at the stack trace in the exception report from JUnit, you should be able to track the problem from the specific assertion that failed all the way back to the specific line of code that threw the exception. So you know where to fix the problem!

The fix is to do some string manipulation. The String class has methods length() and substring(start, end) which you'll find handy. It won't be pretty.

Try your procedural driver!

Object-Oriented Solution

The object-oriented solution turns out to be really easy.

@Test
public void shouldInterpretStrings() {
        assertEquals("foo", myInterpreter.interpret(new StringETIR("foo")));
}

The compile fails because OOHobbesInterpreter#interpret(IntegerETIR) takes an IntegerETIR as an argument. You're giving it a StringETIR here. This being an object-oriented solution, you should imagine that the solution involves inheritance. Both IntegerETIR and StringETIR implement an interface named ExpressionTIR.

It turns out, in this case, that you could go as high as Object for this parameter's type because the only method you're calling is Object#toString(). And that method has been overridden in the ways you want for both IntegerETIR and StringETIR.

At first, the driver will fail, but you can fix this by removing the (IntegerETIR) cast.