Support for external class type hints in constructor/method (for DI auto injection)

[navisoft]

Hi,

I'm currently working with ext-php-rs and ran into a limitation regarding type hints for constructor and method parameters.

Problem

I would like to accept instances of classes defined outside the extension (e.g. from userland or other extensions like Swoole) directly in constructors/methods, with proper type hints so that DI containers can auto-inject them.

For example:

public function __construct(Swoole\Http\Request $request) {
}

At the moment, I couldn't find a way to declare such type hints using ext-php-rs.

Current workaround

The only approach I found is to create wrapper classes inside the extension (e.g. wrapping Swoole\Http\Request into a Rust-defined class). However, this is not scalable since:

There can be many external classes
It introduces unnecessary boilerplate
It defeats interoperability with existing ecosystems (like Swoole, Laravel container, etc.)
Expected behavior

Ideally, it should be possible to:

Declare constructor/method parameters with external class type hints
Receive them as Zval, ZendObject, or a typed abstraction
Let PHP handle type validation (based on class name)

Something like (pseudo-Rust):

pub fn __construct(#[php(argument, name = "Swoole\\Http\\Request")] request: Zval) -> Self {
}

with a way to attach a class type hint (Swoole\Http\Request) to the parameter.

Questions
Does ext-php-rs currently support type hints for external/userland classes?
If not, is this feature planned?
Is there a recommended pattern for DI-friendly APIs without wrapping every external class?
Additional context

This feature would be especially useful for:

Dependency Injection containers
Framework integrations (e.g. Swoole, Laravel)
Middleware / HTTP handling abstractions

Thanks!

[cookesan]

The low-level type system can represent a class-name object hint, but I do not see a documented macro attribute that attaches an arbitrary external class name to a Zval parameter.

In source, DataType::Object(Some("Class\\Name")) is able to build a Zend class type, and &ZendObject, &mut ZendObject, or Zval are valid ways to receive object values. The function/method macro path, though, derives the argument type from the Rust parameter's FromZvalMut::TYPE. For a generic Zval or ZendObject, that gives an object/zval parameter, not a specific external class such as Swoole\Http\Request.

For now I would use one of these patterns:

pub fn __construct(request: &mut ZendObject) -> PhpResult<Self> {
    // validate the object's class name here before using it
}

or hand-author the function metadata with Arg::new(..., DataType::Object(Some("Swoole\\Http\\Request"))) if you need the PHP signature to carry that exact type. If this needs to work through #[php_impl] ergonomically, it looks like a feature request for an argument-level class-hint attribute.

[ptondereau]

Hello and thanks for the thread!

Indeed, the runtime supports class-typed arginfo, but the proc-macro layer does not expose it.
Just small things to add to the discussion:

• Class-typed arginfo on internal functions is only instanceof-checked in debug builds. On non-debug PHP, the handler runs without type verification. The arginfo is valuable for reflection (what DI containers read) and IDE stubs. Runtime validation rests on the handler's job.
• &Zval maps to DataType::Mixed (PHP mixed), not zval
• PHP resolves the class name lazily at call time, so the external class does not need to exist when the extension loads.

So yes, we could have some

#[php_impl]
impl MyClass {
    pub fn __construct(
        #[php(type_hint = "Swoole\\Http\\Request")] request: &ZendObject,
    ) -> Self { /* ... */ }
}

But it will remain only for type hinting, and your Rust code should still validate the object type if correctness matters.

As a workaround, you can use the FunctionBuilder along with Arg::new("request", DataType::Object(Some("Swoole\\Http\\Request"))) instead of using a macro.

I'm open to a PR for the macro part