This is exactly what you are doing? Saving the string, if the expression is in square brackets, or evaluating it as a number and leaving the string null otherwise? Good, if so, although your immediately following paragraph makes me wonder...
Ah, I was still setting it by initializing the values as "" in registerMonster, which would then call a new "Monster" with the "" value in the case of static mobs. I'll change that to not create a default "" anymore though and change the length checks to null checks.
The chaos I was referring to is if you have null and initialized strings mixed, and don't check for null at the start of every call, you'll often get a segfault. I somewhat recently converted a mud coded in C to compile/run with pedantic, Wall, and Werrors on, and then converted the memory handling to actually care about memory being released twice/not initialized properly. It took several months to find all the parts where it had been done poorly in the past, but it's been running fine and stable for a few months now and I feel better about it in general.
Anyways, moving back to Java and this, it doesn't currently check for the brackets. I got quite confused looking through Modifiers for where the bracket handling happens. What I used was... well, let me give an example.
PHP:
if ( option.equals( "HP:" ) )
{
if ( tokens.hasMoreTokens() )
{
value = tokens.nextToken();
if (StringUtilities.isNumeric(value)) health = StringUtilities.parseInt( value );
else evaluatehealth = value;
continue;
}
}
The only change there is testing if the value is numeric. If so, it gets passed to parseInt. isNumeric is the same test used (in line 694) in parseIntInternal1 to decide if a string is cleaned up enough to run through parseInt.
If it would fail parseInt, there's no sense in trying to pass it on. Whether we bracket it or not, it'll fail. If we throw a test like value[0] == '[' into the saving of the expression, the question becomes what to do with expressions that fail that... do we want it to still try to evaluate them, or do we want them to void that monster?
Update: Tried sending uninitialized string, compile failed.
[javac] C:\kolmafia\src\net\sourceforge\kolmafia\persistence\MonsterDatabase.java:413: variable evaluatehealth might not have been initialized
[javac] return new Monster( name, health, attack, defense, initiative, attackElement, defenseElement, minMeat, maxMeat, poison, evaluatehealth, evaluateattack, evaluatedefense, evaluateinit );
So, do I go back to testing string length, do I construct a different form of Monster that has the strings, do I send the strings on each and evaluate it on creation...? Hmm, that probably wouldn't slow it down QUITE as much, but should fix the crashings...
Can't leave anything uninitialized, apparently...
[javac] C:\kolmafia\src\net\sourceforge\kolmafia\persistence\MonsterDatabase.java:477: variable evaluatehealth might not have been initialized
[javac] }
Can't leave uninitialized, but can initialize to null. This works. Or compiles, at least.
PHP:
if (StringUtilities.isNumeric(evaluatehealth)) { this.health = StringUtilities.parseInt( evaluatehealth ); this.evaluatehealth = null; }
else { this.evaluatehealth = evaluatehealth; this.health = 0; }
Sorry... I've put together the 3 files, the other 2 classes are extending the original Evaluator class. modifier_eval shows me that the ModifierEvaluator class is working as it should. The original code of the evaluate is what still needs to be redone.
Ah well, so it goes. May be a while before I get the original function recoded. We'll see.