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

On Wed, Jan 14, 2015 at 8:10 AM, Andi Gutmans <andi@zend.com> wrote: > >> 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 :) I fully agree. JNI is crap. However, let face it, our internals APIs is really not good. Yes, there were/are on going efforts for small parts but overall it is a pain to achieve simple things. -- Pierre @pierrejoye | http://www.libgd.org