Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80315
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
References: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
Date: Sat, 10 Jan 2015 01:48:30 +0000
Message-ID: <CAKxcST83pXKCqK8bYDBTn85oWMuqYYczfgg8LHGo=e5jRfv2Bg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP Internals List <internals@lists.php.net>, 
	"Pierre (php.net gtalk)" <pierre.php@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2c01e676eee050c4278ba
Subject: Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
From: dragoonis@gmail.com (Paul Dragoonis)

--001a11c2c01e676eee050c4278ba
Content-Type: text/plain; charset=UTF-8

On 10 Jan 2015 01:10, "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.
>
> 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?

Hi Sara,

Somewhat Pie in the sky but at the same time also achievable with good
planning and design. I'd support this definitely and this abstraction layer
would solve constant maintainability of extensions by not having to update
themselves constantly to support latest versions of PHP due to a lack of
abstraction.

Did that make sense ?

>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--001a11c2c01e676eee050c4278ba--