Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80443
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.214.169 as permitted sender)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
Date: Tue, 13 Jan 2015 23:10:56 -0800
Cc: Pierre Joye <pierre.php@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <EED0D760-877C-463C-A663-8415381E7A10@zend.com>
References: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Subject: Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
From: andi@zend.com (Andi Gutmans)


> On Jan 9, 2015, at 5:10 PM, Sara Golemon <pollita@php.net> wrote:
>=20
>> 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.
>=20
> 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.
>=20

I was a *very* heavy user of JNI. Sucked big time. You pay a high price for t=
rying to keep a consistent API and marshaling. While this is slightly differ=
ent I don't see how you avoid some of the additional overhead plus it will b=
e very challenging to really cover everything that's needed.=20
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.
>=20
> What do you think?
>=20
> -Sara
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20