• 5 Posts
  • 11 Comments
Joined 8 months ago
cake
Cake day: January 25th, 2024

help-circle






  • Thank you for your detailed response.

    I am ok using macros. But even proc macro only get the tokens and using in on the whole mod is unstable unless you use use it on mod sth{...} instead of code being on in a different file (sth.rs).

    The plug-in system is dynamic in a sense that my plans for it are loading them through shared libraries (.dll, .so) compiled separately by users. But I also have internally provided core plugins that come with the program. But rust ABI system is not that stable, so in worst case I might have to ask users to just add plugin code to some directory and re-compile program instead of loading from shared libraries. That’s why I’m trying to make it as simple as possible. Asking users to modify the rust code somewhere else yo register the plugin might be met with resistance.

    I was thinking that using build script to parse the source code and generating those codes could work, but that seemed hacky. So I was trying to see if there are better solutions, as it felt like a problem people might have come across themselves.


  • Thank you. I just put the call with !, I don’t necessarily want a macro solution. Any solution is acceptable, my requirement is that I can just keep adding more mods with functions in src/functions/ and not have to register each function.

    Inventory seems like the solution I am looking for. Although in my case, instead of collecting different values of the same type, I want to collect different types that all have same trait. But maybe I can make a temporary struct with Box<dyn _> member to collect it if trying to collect it directly doesn’t work. I do not plan to support WASM. I am planning to make C/C++ and Python API for the libraries though, so if it has problems with them, then I might have a problem.