Recently, I set an assessment for my students, which consisted of filling in the application logic behind a calculator GUI that I supplied. One of the difficult parts of this code is writing the functionality behind the decimal point button. The button needs to effect a mode-change so that clicking on the number buttons in the interface places those numbers after the decimal point rather than before it. The obvious way to do this is to set some kind of boolean flag and then to monitor this flag in the part of the program that deals with numerical input. So far, fairly easy.
The difficult part of this is dealing with turning the flag back to normal input. The end point of inputting a number consists of clicking on one of the binary operation buttons or clicking on the equals button. In both of these cases the current number-entry process comes to an end, and a new number entry is started. However, to implement this change, we have to put a piece of code into each of those button pushes. This would seem to contradict ideas of locality in programming; the code concerned with dealing with the decimal point becomes splayed across the code.
I wonder if some hypothetical computer language could provide some means of implementing this more locally to the original functionality. For example, would it make sense to list at the end of the code that set the flag all of those methods where it needed to be reset? Here is some pseudocode:
public void decimal() {
decimalFlag = true;
afterMethods (add,subtract,multiply,divide,equals) {
decimalFlag = false;
}
}
There is a different kind of locality problem now; a method such as add no longer contains everything that it does, as the ending of the method changes the flag, despite this not being written explicitly in the method. Perhaps with modern IDEs this isn’t a problem: we could have the IDE automatically display a link to lists of these after-method actions (that raises a more general question of how computer languages could be different in a world of sophisticated IDEs).
More generally, this raises an interesting issue about the semantics of methods. We are accustomed to methods having a kind of “wait until explicitly trigged” semantics; they are only triggered when a specific method call is carried out elsewhere in the program. An alternative is some kind of “wait until conditions are right” semantics, where the conditions for a method to be called are contained within the method itself. But, exploring that is a matter for another time.
