Re: One API to rule them all? (Was: Extension Prepend Files)

> On Jan 9, 2015, at 5:10 PM, Sara Golemon <pollita@php.net> wrote: > >> On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye <pierre.php@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. > I was a *very* heavy user of JNI. Sucked big time. You pay a high price for trying to keep a consistent API and marshaling. While this is slightly different I don't see how you avoid some of the additional overhead plus it will be very challenging to really cover everything that's needed. Just my 2 cents. Had to respond because of how crappy JNI was/is :) Andi > 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 >