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