Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implicit #[php_module] can be akward #131

Open
vodik opened this issue Apr 1, 2022 · 1 comment · May be fixed by #174
Open

Implicit #[php_module] can be akward #131

vodik opened this issue Apr 1, 2022 · 1 comment · May be fixed by #174
Labels
bug Something isn't working

Comments

@vodik
Copy link
Collaborator

vodik commented Apr 1, 2022

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:

#[php_module]
pub fn module(module: ModuleBuilder) -> ModuleBuilder {
    module
}

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:

#[php_module]
pub fn module(m: &Module) -> Result<()> {
    m.add_class::<MyClass>()?;
    Ok(())
}

That will allow module to appear anywhere in the project.

@vodik vodik changed the title Implicit #[php_module] makes code splitting akward Implicit #[php_module] can be akward Apr 1, 2022
@davidcole1340
Copy link
Owner

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.

@davidcole1340 davidcole1340 added the bug Something isn't working label Apr 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants