Or, we could do a fair bit of whackage to how ASH functions are invoked internally.
The public way to execute an ASH function is in Interpreter.java:
Code:
public Value execute( final String functionName, final String[] parameters )
or
Code:
public Value execute( final String functionName, final String[] parameters, final boolean executeTopLevel )
Note that "parameters" is an array of String objects.
These end up calling:
Code:
private Value executeScope( final Scope topScope, final String functionName, final String[] parameters,
final boolean executeTopLevel )
and
Code:
private boolean requestUserParams( final Function targetFunction, final String[] parameters, Object[] values )
That last method gets the parameter list from the targetFunction and iterates over it, taking input Strings from the parameter list (until it runs out) or prompting the user (thereafter). For each function parameter/string value pair, it coerces the string into the desired data type by calling:
Code:
value = DataTypes.parseValue( type, input, false );
That is how the monster name ends up as a $monster value, if the consult script says the second prameter is a "monster" rather than a "string".
The above is exactly how we want it to behave if you are calling an ASH function from the CLI: you specify the function name, give it a comma delimited list of strings to use as parameters, and if you didn't give enough, we prompt.
So, when a consult script is invoked internally, as you saw from the code I first cited, we pass it an array of strings - just as if the user had typed those.
Seems to me we could change the above four methods to all take Object[] parameters. And then, we would call DataTypes.parseValue( Type, String, boolean ) ONLY if the parameter was a String. Otherwise, we'd call a new method: DataTypes.coerceValue( Type, Object, boolean ), which would try to convert the Object into a Value of the specified type, using other methods already available in the DataTypes module. For example:
Code:
public static final Value makeItemValue( final AdventureResult ar )
or
Code:
public static final Value makeMonsterValue( final MonsterData monster )
That last one would be what would be used if we invoked a consult script like this:
Code:
Object[] parameters = new String[3];
parameters[0] = IntegerPool.get( FightRequest.currentRound );
parameters[1] = MonsterStatusTracker.getLastMonster();
parameters[2] = FightRequest.lastResponseText;
consultInterpreter.execute( "main", parameters );
The round number would be a real integer and would thus not be converted to a string and parsed back into an integer.
The monster name would now be the real monster object - the same one you get from last_monster().
That actually doesn't seem that difficult. Seems odd to change the whole mechanism in which we invoke ASH functions in order to change how we invoke consult scripts, but, what the heck.