search

sdleffler / hv-dev

Slow down, upon the teeth of Orange: Heavy is an opinionated, efficient, relatively lightweight, and tightly Lua-integrated game framework for Rust.
Apache License 2.0
14 stars 1 forks source link

integrate tealr #4

Open lenscas opened 2 years ago

lenscas commented 2 years ago

How are we going to do this?

Right now, the fork supports the add_type_methods method in hv_lua's userdata. This is done in such a way that it doesn't require changes in the tealr_generate_docs crate.

However, I'm not sure if I did the TypeBody implementation for the new types introduced by hv_lua correctly and I am probably missing some of those as well.

Further things: tealr is normally compatible with both mlua and rlua. Right now, that compatibility is broken in the fork but not entirely removed.

tealr + branch that I use as "fork" for FishFight : https://github.com/lenscas/tealr/pull/39

edit: It might be possible to reverse the dependency, tealr doesn't care if you have enabled one of the backends or not. And the TypeWalker struct only cares about things having implemented A: 'static + TypeName + TypeBody.

Then it might be possible to add support for everything that hv_lua does to tealr without actually forking tealr.

TealData can then simply be merged with the UserData from hv_lua. So, I don't think that this is a problem is it is just some extra bounds on UserData that are needed.

TypeName has a new (default) method to generate the name of a Userdata type (with a Userdata type I mean the userdata that can be used to create dynamic queries and which also gets methods through the add_type_methods method)

TypeWalker has a new method (process_type_as_marker) to get all the information for a Userdata type.

Both of those would require another solution. I think it is possible to solve both of them by working with a Type<T> instead of a T though it would mean that you won't be able to modify what the name is of a Userdata type.

Lastly, some things would need to be reimplemented on hv_lua's side regardless as they are only accessible if a backend is selected. These are: The generic macro (and optionally, the premade generics) https://github.com/lenscas/tealr/blob/master/tealr/src/mlu/generics.rs

the Union macro https://github.com/lenscas/tealr/blob/master/tealr/src/mlu/picker_macro.rs

and lastly, the TypedFunction https://github.com/lenscas/tealr/blob/master/tealr/src/mlu/typed_function.rs

The types that hv_lua exposes need to implement TypeName and unless they are built in to lua also need to implement TypeBody.

lenscas commented 2 years ago

I thought a bit more about if it would be better to fork tealr or swap the dependency order.

Swapping the dependency order would introduce some more boilerplate to hv_lua, but most of that lives/will live in tealr anyway so I don't think it matters much, and it will probably lower boilerplate overall (As people then can just implement UserData instead of UserData AND TealData).

The Union macro is not even that useful right now due to how mlua (and I assume hv_lua as well) try to convert everything. So no big loss if that doesn't get copied over.

Typed function and the generic stuff can just be copied over as is and are probably important enough to do so. Same for the implementation of TypeName for the types that mlua provides (so, String,i32, bool, Vec, etc)

So, all in all, it shouldn't increase the amount of stuff in hv_lua that much, and most of the stuff would need to live somewhere anyway and the current implementation can just be copied over.

sdleffler commented 2 years ago

I think swapping the dependency order is the easiest way. I don't mind adding new stuff to hv-lua at all, as long as I buckle down and hack it in. Adding new stuff to UserData is A-OK and honestly something I'd really rather encourage, it's the whole reason that I forked mlua in the first place.