Hey Sara, > On 10 Jan 2015, at 01:10, Sara Golemon <poll...@php.net> wrote: > > 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?
Yes, I like this idea. Three APIs for TheFacebook under the sky, Seven for the Zend-lords in their halls of stone, Nine for the Engines doomed to die, One for the Dark Lord on his dark throne, In the Land of Native where the Undefined Behaviours lie. One API to rule them all, One API to find them, One API to bring them all and in the darkness bind them In the Land of Native where the Undefined Behaviours lie. *ahem* Er, sorry about that. I think this is a good idea. Most PHP extensions do not require tight coupling to the Zend Engine (or indeed HHVM). Something simple which exposes class, function and constant definition, and abstract PHP value (zval) handling, would be enough for the vast majority of extensions, I should think. There’ll always be a place for tightly-coupled extensions which need to use the engine’s “native” API, but something simple and cross-implementation would work for most extensions, allow better cross-implementation PHP code compatibility, and generally be a Good Thing(TM), I think. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
