[RFC] [FFI] Opt-in mapping of C struct types to userland PHP classes View as Markdown

Hi internals,

I'd like to check interest in an FFI improvement before writing a formal
RFC. I've filed the full proposal with an implementation sketch as a
feature request:

https://github.com/php/php-src/issues/23229

The problem: every C value FFI produces - a zend_string*, a zval*, a char*

• is one and the same final class, FFI\CData. That single opaque type is
  what makes FFI flexible, but it also means no C struct a binding works with
  can ever be described to static analysis or an IDE,
  and CData being final closes off every userland workaround.

Today a binding that wants any static typing has to ship a code generator
emitting analysis-only stub classes, a .phpstorm.meta.php map, and an
analyser extension - and the result is still strictly weaker than the real
thing: instanceof can never work and native parameter types can never be
enforced. I maintain the lisachenko/z-engine framework, which drives the
Zend Engine's own structs through FFI, and I ship exactly that four-part
workaround; every FFI binding generator hits the same wall.

The proposal: an opt-in, per-scope class map, configured through an options
array in the spirit of SoapServer/SoapClient:

$ffi = FFI::cdef($code, $lib, options: [
    'classmap' => [
        'zend_string' => \My\Engine\ZendString::class,
    ],
    'typemap' => [ /* C type => marshalling callbacks */ ],
]);

final class ZendString extends \FFI\CData
{
    public int $len { get => ...; }   // property hooks over raw fields
}

With a type registered, every handle ext/ffi mints for it - from
FFI::new(), FFI::cast(), struct-field reads, function returns - is an
instance of the mapped class instead of bare CData. get_class() is
truthful, instanceof works, and native parameter/return declarations are
enforced by the engine.

Implementation-wise this stays local to ext/ffi and is zero-overhead when
unused: the object storage remains zend_ffi_cdata with shared handlers,
only the ce pointer differs, so GC, clone, field access and lifetime behave
byte-for-byte as today. The only relaxation is that FFI\CData becomes
extendable for registered classes. Fully opt-in, no BC impact.

I'm targeting PHP 8.6 ahead of feature freeze and volunteering to write the
implementation PR - z-engine already emulates these exact semantics in
userland, so there's a strong real-world test bed for it.

The main open design point I'd like feedback on is the typemap callback
contract (from_cdata/to_cdata, and when they fire) versus shipping classmap
alone in the first iteration.

If the feedback here is positive, I'll write this up as a formal RFC on the
wiki.

Regards,
Alexander Lisachenko