> On Jan 9, 2015, at 5:10 PM, Sara Golemon <poll...@php.net> wrote:
> 
>> On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye <pierre....@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
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to