On Fri, Jan 9, 2015 at 5:41 PM, Andrea Faulds <a...@ajf.me> wrote: > 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. > *slowclap*
> 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. > Exactly. This is what we learned from making ext_zend_compat. Basic glue extensions are the majority, those places where a lot of extensions currently "link deep" are simply because they can, but not because they need to. > 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. > For the handful that do funky stuff like OpCache+, Xdebug, etc... They can explicitly reach behind the artifice with the understanding that they're not necessarily going to work from version to version without loads of #ifdefs and kinky machinations. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
