Re: One API to rule them all? (Was: Extension Prepend Files)
| From: | Sara Golemon | Date: | Sat, 10 Jan 2015 01:46:53 +0000 |
| Subject: | Re: One API to rule them all? (Was: Extension Prepend Files) | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-80314@lists.php.net to get a copy of this message | ||
On Fri, Jan 9, 2015 at 5:41 PM, Andrea Faulds <ajf@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