You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something I've been wanting to do for a while is to remove support for the implicit #[php_module]. As it stands, you currently can just drop this at the bottom of your file and have everything register automatically:
Since macros run in order, you must make sure that the module function is the last thing the build sees. If anything is created after the fact, the build will fail with very usefulness error messages.
Code splitting / rust modules are harder to use.
In one of my larger projects, I split code into a few files. I have to make sure my main lib.rs imports everything in order for it to build. This in turn interacts makes my main module harder to read when I have conditional features split over multiple files.
Alternative
Follow the similar pattern which pyo3 does: explicit registration. I think its more predictable:
Yeah, the macro crate uses a global state (which is unrecommended and actually UB by the compiler). I ran into issues with this when using rust-analyzer (see #99), so I think it's best to finally remove the global state. This will probably be next up on my to-do list.
Something I've been wanting to do for a while is to remove support for the implicit
#[php_module]
. As it stands, you currently can just drop this at the bottom of your file and have everything register automatically:Two problems arise quickly with larger projects:
Order matter
Since macros run in order, you must make sure that the module function is the last thing the build sees. If anything is created after the fact, the build will fail with very usefulness error messages.
Code splitting / rust modules are harder to use.
In one of my larger projects, I split code into a few files. I have to make sure my main lib.rs imports everything in order for it to build. This in turn interacts makes my main module harder to read when I have conditional features split over multiple files.
Alternative
Follow the similar pattern which pyo3 does: explicit registration. I think its more predictable:
That will allow
module
to appear anywhere in the project.The text was updated successfully, but these errors were encountered: