Currently the Bevy API is generated mostly with the help of meta-programming, it would be better to have a smart trait system and smaller macros.
We could create a UserDataMethodsExt trait which would have the same interface but have different bounds on the arguments (namely LuaProxyable or equivalent)
Alternatively we could have some sort of Proxy and Unproxy trait pair, which given a system for controlling world access to components at runtime, could collect the required accesses and then carry out wrapping and unwrapping automatically.
This would solve a lot of the current problems including the lackluster support for collections, results, options etc (we could just implement Proxy and Unproxy for these)
Currently the Bevy API is generated mostly with the help of meta-programming, it would be better to have a smart trait system and smaller macros.
We could create a UserDataMethodsExt trait which would have the same interface but have different bounds on the arguments (namely LuaProxyable or equivalent)
Alternatively we could have some sort of Proxy and Unproxy trait pair, which given a system for controlling world access to components at runtime, could collect the required accesses and then carry out wrapping and unwrapping automatically.
This would solve a lot of the current problems including the lackluster support for collections, results, options etc (we could just implement Proxy and Unproxy for these)