Adding strings and integers
Interpreters, Iteration 7

User Story

Back to this story, with a clarification:

In order for this to work, you have to now be sensitive to the type of data that you're working with. Previously, you've assumed that the data in an addition was integer. Now you have to check.

Procedural Solution

If you deal with other operators (like multiplication), you'll probably want to first decide which operator you have and then deal with the operands. You want to shoot for code like this in interpret(Tree):

if (tree.getText().equals("+")) {
  return add(tree.getChild(0), tree.getChild(1));
} else if (tree.getText().equals("*")) {
  return multiply(tree.getChild(0), tree.getChild(1));
} else {
  throw new IllegalArgumentException(tree.getText() + " is unrecognized");
}

This reduces your problem to the add(Tree,Tree) method. Get the tests complaining about this first.

The red bar should be a complaint about turning one of your STRINGs into an int. That's happening in add(Tree,Tree). That's where you're assuming that you have INTEGERs. Your code shouldn't make this assumption any more.

You haven't fixed the STRING issue, but you should get a different cause for the red bar: the default-case exception. The INTEGER case should still work just fine.

Object-Oriented Solution

New JAR Files

Better Object-Oriented Dispatching

Remember those (IntegerETIR) casts you have in visitOperatorETIR(IOperatorETIR)? They're evil. They're not object oriented.

The problem is that standard OO solutions allow one object to determine which algorithm (i.e., method) to execute. Suppose I had these methods in IntegerETIR for you:

public IntegerETIR add(IntegerETIR) { ... }
public StringETIR add(StringETIR) { ... }

You might be tempted to write this code for visitOperatorETIR(IOperatorETIR):

return operator.getLeft().add(operator.getRight());

Here's the kicker: getRight() officially returns an ExpressionTIR. In the scenario above, there's no add(ExpressionTIR), and so the compiler will complain! You can yell and rant at the compiler: "I know it'll be an IntegerETIR or a StringETIR!" But it won't care.

You could check to see what kind of data it is and then cast it, but checking data types and casting is not object oriented.

This is often known as the binary operator problem. You have a binary operator (addition in this case), and you want to pick which method to execute at runtime based on two objects. Most OO languages (C++, Java, Ruby, Python, etc.) allow you to pick a method at runtime based on only one object—standard polymorphism. To pick a method based on two or more objects, you need multiple dispatch.

The programming language Dylan uses multiple dispatch all of the time. It appears that Perl 6 will have it. Some languages (like Python) allow you to add it. Some have it implemented in a library. You have this last option in Java.

The PolyD library provides multiple dispatch in Java. But instead of working on our data objects, you have to implement an algorithm object. You're already doing something like this with the ExpressionTIRVisitor interface. Your OOHobbesInterpreter is really an algorithm encapsulated in an object. Now you need another algorithm object to encapsulate string-integer addition.

Before you add new features, let's refactor your code into an addition algorithm.

You want to shoot for something like this to handle addition in visitOperatorETIR(IOperatorETIR):

OperatorAlgorithm addition = PolyD.build(OperatorAlgorithm.class, new AdditionAlgorithm());
return addition.add(operator.getLeft(), operator.getRight());

You'll get compiler errors about missing classes and methods.

PolyD needs to know how to dispatch methods based on the arguments passed to a method. You're interested in multiple dispatch, so it'll look like this:

@PolyD
@DispatchingPolicy(MultiDisp.class)
interface OperatorAlgorithm { ... }

So when you have PolyD build an algorithm with this interface (the OperatorAlgorithm.class from earlier), it'll use multiple dispatch (the MultiDisp.class here). And it will dispatch using the methods that you define in AdditionAlgorithm (the new AdditionAlgorithm() from earlier).

So now you just have to add methods to AdditionAlgorithm with the parameters you're really interested in. For example, you could stick with the evil casting code:

But, of course, one purpose of using PolyD is so that you don't have to do the casting.

The real power, though, with multiple dispatch is that AdditionAlgorithm and PolyD will figure out which add() method should be called no matter what values are passed to it.

The red bar should be due to the exception in add(ExpressionTIR,ExpressionTIR).

The two parameters in an add() method don't have to be the same.