Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80335
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.176 as permitted sender)
Message-ID: <54B1AA31.6050703@gmail.com>
Date: Sat, 10 Jan 2015 14:39:45 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Sara Golemon <pollita@php.net>, Pierre Joye <pierre.php@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
In-Reply-To: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 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,

What extensions do right now is pretty closely linked to how the engine
is functioning. Of course, for simple things like "take number from C
library, wrap it in zval, send to PHP" the API would be pretty simple,
but if you have something like simplexml, it relies a lot on the details
of the engine and how things are done there.

So I think it would be useful to define what exactly would be covered
and what not, i.e. which APIs are supported, which can be supported,
which can not. Right now we don't even have the API as such for the
engine itself (i.e., you can just go to EG(...) or bits of the zval and
mess with them, and not only you can but many extensions do).

Also I wonder how that would sit with phpng effort. Lately it was very
focused on performance-based optimizations, and working via abstract
APIs may not be always the most performant way of doing things.

> learn from.  Heck, we're actually halfway there with HHVM's
> "ext_zend_compat" layer, which makes PHP extensions (mostly) source
> compatible with HHVM.

Is there some docs for what ext_zend_compat does and which APIs it
supports/doesn't support?
-- 
Stas Malyshev
smalyshev@gmail.com