unpredictable type inference #60

New Issue

2019-05-15T20:57:27Z

NQNStudios commented

2019-05-15 20:57:27 +00:00

(Migrated from github.com)

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.

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 commented

2019-05-15 20:58:44 +00:00

(Migrated from github.com)

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

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 commented

2019-05-15 22:44:35 +00:00

(Migrated from github.com)

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 commented

2019-05-15 22:47:28 +00:00

(Migrated from github.com)

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

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 commented

2019-06-04 16:42:40 +00:00

(Migrated from github.com)

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.

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 commented

2019-06-04 17:00:21 +00:00

(Migrated from github.com)

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

NQNStudios commented

2019-06-04 21:09:29 +00:00

(Migrated from github.com)

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

NQNStudios commented

2019-06-06 20:33:38 +00:00

(Migrated from github.com)

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