Demo project for comment, and my own thoughts on the Bevy API.

[LaserWitch]

As touched on in #65 I have a little demo project that I've been using for prototyping, and it encapsulates both my expected usage and my hacks in service of #65 and #69 pretty well. That project is now public at https://github.com/LaserWitch/lw_bevy_lua_demo. The code is rough in spots, and probably the documenting too, but it currently checks all the boxes I expect to need checked for my game project. Any pointers for improvement or other thoughts on it would be useful, and anything that can be made a crate feature you're welcome to lift of course.

After working with it a bit, the provided bevy API is surprisingly solid in many ways. I originally expected to need to do more work myself when it came to providing direct access to fields on components. My thoughts on potential areas of improvement might show in where I wrote helpers, but I'll try to think of them now...

• Adding functions to an API is somewhat crunchy syntax. A few macros to ease that might make sense, though just helper functions might be as good in many cases...
• Which brings to mind a more meta point: the crate can take a long time to build, which I found when I was making and testing changes on pr branches. Not sure if macros are the cause or not, or if it's avoidable, but seems worth mentioning.
• I have (Vec3) component that's Deref and DerefMut, and if memory serves I needed to do v.1 in lua to get at it's components at all. That surprised me.
• I believe at one point I had a Vec<> that was exposed to lua, and I found that it was 0-indexed and lua's length() reported it one element shorter than it actually was.
• I think we have to register any tuple type we're going to expose to Lua, which might be unavoidable but was an unpleasant surprise.
• How we're able to just stack up API providers is quite nice. The one questionmark I am left with is if it's possible to for two API providers to provide world methods without conflict...
• Also it'd be nice if we could iterate over userdata members with pairs() but I think that's probably deeper Lua nits.

That's what I can recall right now!

[makspll]

Great work! I am a bit stretched for time right now but I'll be trying to incorporate a lot of the features discussed recently into the next release (albeit slowly). Your feedback is invaluable and thank you for taking the time to write it out!

After working with it a bit, the provided bevy API is surprisingly solid in many ways

That's good to hear! it's in very early stages at the moment and I am also quite surprised myself haha!

[makspll]

• Adding functions to an API is somewhat crunchy syntax. A few macros to ease that might make sense, though just helper functions might be as good in many cases...
• Which brings to mind a more meta point: the crate can take a long time to build, which I found when I was making and testing changes on pr branches. Not sure if macros are the cause or not, or if it's avoidable, but seems worth mentioning.
• I think we have to register any tuple type we're going to expose to Lua, which might be unavoidable but was an unpleasant surprise.
• Also it'd be nice if we could iterate over userdata members with pairs() but I think that's probably deeper Lua nits.

The crate has since gone a significant re-write which I would hope eases these points! The bindings are 1000x easier to write, can be attached to ANY type very easilly, and any types involved are automatically registered (and we make use of dynamic type checking for container types). You can also call stuff like :functions to get all dynamic functions available on types!