4 ms·
I am integrating Wren into a game via wrenbind17. My codebase is C++. So far it is relatively smooth. Wren itself and the fibers support and language in genera
by germandiago 4y ago
I am integrating Wren into a game via wrenbind17. My codebase is C++.
So far it is relatively smooth. Wren itself and the fibers support and language in general are simple and great tools that have helped me a lot.
But I also want to list things I would like to be smoother to integrate.
This is probably half of it Wrenbind17 limitations more than Wren, Idk, but here I go.
1. Cannot expose enum constants easily.
2. Inheritance: if I create a subtype of A, being that subtype B and I creatr in Wren a B subtype, I cannot call A methods. This is painful.
3. Exposing classes was pretty easy BUT exposing state from C++ was a bit more challenging. I had to do something like (by generating code):
```
var State = null
class StateSetter {
static set(State s) {
State = s
}
}
```
On the C++ side a variable pf that type is exposed, set is called on the C++ side and the var State imported.
4. In Chaiscript callbacks can be exposed directly with no wrappers. In Wren I am not sure it is possible. Had to wrap stuff (look at Wrenbind17 fot an example).
5. No static properties or constants made a lot pf boilerplate to expose just enums (had tp wrap in functions each enum value.
All in all Wren is working pretty well. Even I could expose nlohmann json as its own jso type and make it work natively with zero casting as it should work in a dynamic language.