On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye <pierre....@gmail.com> wrote: > The fact that hhvm implements a significant part of the extensions (or > other areas) using PHP+additional syntax as well as adding cleaner > APIs or mechanisms for the C parts only confirms me one thing: the > very 1st problem we have to solve is to ease the extension creation, > by drastically changing the internals APIs & tools. Bundling script > does not help here, we are using a scotch tape to repair something > that should have been replaced or redesigned since long already. I am > not blaming anyone, the engine design, historically, does not make > such changes easy. > Funny to see you mention this. I literally just pulled together a meeting today to discuss HHVM's admittedly unstable extension API. One idea to emerge from this was to design a new extension API agnostic of underlying implementation. An API which, if done right, could be adapted equally to both PHP7 and HHVM *and* provide the opportunity to introduce PHP5 shims so that a single extension could be written to function identically under any PHP runtime, and any version. If done right, could make extensions not just source compatible, but *binary* compatible as well. The engine details can change, but the public-facing extension API could offer a consistent way of doing the one and only thing that extensions should have to do: Glue PHP into external libraries.
That's a bit pie in the sky, I'll admit, but wouldn't that be cool? Fact is, JNI does this for Java already, so there's precedence to learn from. Heck, we're actually halfway there with HHVM's "ext_zend_compat" layer, which makes PHP extensions (mostly) source compatible with HHVM. While I could work on this in the dark, manipulating HHVM's APIs with one hand and adding proxy interfaces to PHP (as an extension) with the other, I'd much rather have involvement from others. What do you think? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
