Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80311
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.215.47 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
Date: Fri, 9 Jan 2015 17:10:04 -0800
Message-ID: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: One API to rule them all? (Was: Extension Prepend Files)
From: pollita@php.net (Sara Golemon)

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.

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