What started out as refactoring rapidly became rewriting and has now advanced to reimplementing.
I have stepped waaaaaay back on my Expression Evaluator. There was a wee bug in comparing values that showed a flaw in the way it all works. I had a small Eureka moment and found this description for an expression:
* <pre> EXPRESSION ::= ID "=" ELEMENT
LOGICAL_OR ::= LOGICAL_AND "||" LOGICAL_OR
LOGICAL_AND ::= COMPARE "&&" LOGICAL_AND
COMPARE ::= SUM "<" SUM
| SUM "<=" SUM
| SUM "==" SUM
| SUM "!=" SUM
| SUM ">=" SUM
| SUM ">" SUM
SUM ::= TERM "+" SUM
| TERM "-" SUM
TERM ::= FACTOR "*" TERM
| FACTOR "/" TERM
FACTOR ::= PRIMARY "^" FACTOR
| PRIMARY "%" FACTOR
PRIMARY ::= "-" ELEMENT
| "!" ELEMENT
ELEMENT ::= ID
| "(" EXPRESSION ")"
So each item is a class of it's own and I can build the hierarchy quite easily.
The first go at evaluation works well, but then comes re-factorisation pain. Most of the types have two sides so the super class takes two expressions. What I then wanted to do was process the two sides, validate them and then bring them together. I come up with a interface and it works.
Bollocks does it. It has to evaluate both sides, so I need to complicate things by deciding if it should continue after the first evaluation. I'm thinking of just making it support any number of the same type of expressions and allow it to evaluate them one after another and decide when to stop.
Re-Write City Arizona, here I come!
Reality is an illusion caused by a lack of alcohol
So this means you can't XOR comparisons (often written as a != b where a and b are comparisons), right? Because you also skip the bitwise operators. Writing a XOR the long way around is kind of tedious.