Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80444
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <EED0D760-877C-463C-A663-8415381E7A10@zend.com>
References: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
	<EED0D760-877C-463C-A663-8415381E7A10@zend.com>
Date: Wed, 14 Jan 2015 08:30:35 +0100
Message-ID: <CAEZPtU7FHJQKQo-Zdoii3-CTY=koh1pXs4Dn5uzzgYFWSwd5fw@mail.gmail.com>
To: Andi Gutmans <andi@zend.com>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
From: pierre.php@gmail.com (Pierre Joye)

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> wrot=
e:
>>> 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 f=
or trying to keep a consistent API and marshaling. While this is slightly d=
ifferent 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.


--=20
Pierre

@pierrejoye | http://www.libgd.org