That's the problem: Since only incr and decr exist, a bool is enough to say which of these two operatios should be done. But when you add a third, the bool isn't enough. So you either change the opcode to an int, like the autor, or branch the mul instruction away above like above solution.
1. If you don't do arithmetic on it and it's not a primary key then it's not a number (eg an employee number might be "123456" but it's a string not a number); and
2. It's almost never a boolean; it's an enum.
I've lost count of the number of times I've had to change a boolean to an enum (some of which I created in the first place).
My favourite hack for this is when someone decides to add a third value to a boolean with:
Optional<Boolean> foo
Nope. You're wrong. It's even more hilarious when they add a fourth value:
Yea, I would prefer an enum over an int to choose the operation, but don’t forget that this is C, where enums _are_ ints. Oh well.
Also, that it turns out there is already an enum to extend for the binary protocol, so the blog author reused that instead of making a new one just for the this one function.
