unpredictable type inference

[NQNStudios]

when variables are assigned values from HInterface.expr() they sometimes inconveniently infer the wrong types and change the values, i.e. stringifying objects. This behavior varies across target platforms, which could cause some tremendous issues if people use hscript in their stories for more than basic string/number manipulation. Be cautious.

[NQNStudios]

This issue forced me to make "true" and "false" (string values) coerce to booleans in a workaround for C++ test coverage: https://github.com/NQNStudios/hank/blob/3d99159102615c2c6d938cc35d664f38c5378a1b/hank/HInterface.hx#L77

[NQNStudios]

If I decide to probe into this deeper, one thing I didn't think to do was check into how exactly the compiled C++ code looks. That could answer a few questions, if not suggest a solution.

[NQNStudios]

Potentially relevant: https://code.haxe.org/category/other/passing-different-types-to-a-function-parameter.html https://haxe.org/manual/type-system-type-parameters.html https://haxe.org/manual/type-system-unification.html

[NQNStudios]

The solution I've had bouncing around my head is that I could transmute assignment operations to actually store the hscript Expr of the assigned value, and when type info is needed on a variable, consult the expr. This would require transmuting lots of other expressions (such as dot access) to unwrap the value from the Expr before operating on it. Maybe another approach, would be to keep a type dictionary inside the hinterface? That might be crazy given that we can consult types at runtime. I'm getting in the weeds with this problem.

[NQNStudios]

I'm wondering whether a Value type like Ink's might help out in this case.

[NQNStudios]

https://haxetink.github.io/tink_core/#/types/any

[NQNStudios]

I wonder if just writing Story.getVariable() to return Any values would avoid these potential problems.