Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80359
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVrj46bT6niYVaUNf9Cz1xsbjEQ4n5JQAdRY5hmy9hD+SA@mail.gmail.com>
References: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
	<54B1AA31.6050703@gmail.com>
	<CAESVnVrj46bT6niYVaUNf9Cz1xsbjEQ4n5JQAdRY5hmy9hD+SA@mail.gmail.com>
Date: Sat, 10 Jan 2015 23:18:14 -0800
Message-ID: <CAEZPtU69RwqFMOCbkFJkBh-y3RHQpVwi1ES4WkOVGDaneWzMOQ@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
From: pierre.php@gmail.com (Pierre Joye)

On Sat, Jan 10, 2015 at 8:08 PM, Sara Golemon <pollita@php.net> wrote:
> On Sat, Jan 10, 2015 at 2:39 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> 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).
>>
> My idea is to cover *most* (but not all) extensions with a narrower,
> simplified API.  As you say, many interactions fall into the "marshal
> this engine value to a C type as needed".  This can cater to the
> bread-and-butter of PHP extensions very well.
>

More than adding a new layer, I would love to see something similar to
hhvm or Zephir available by default. If C is used, then only the
relevant parts have to be implement by the developers, skipping all
the over complicated data mangling, swapping, exchange, etc between
userland and the engine. It is then relatively easy to end up
generating codes for either php, hhvm or any other platform. Using
builtin script (yes, in this case it could be a nice thing), it could
became a very nice way to develop php&co extensions.

For what I can imagine (I did not remotely try to implement it yet) is
to find a way to parse, say, a php script which include custom
sections for C (or C++) codes. We could use comments but I do not like
the idea, mainly because it will be tricky to have editors support :)

One problem, I do not think it is possible to customize the current
lexer to allow that on demand, but it could be possible using a more
modern lexer tools. I am not sure how flexible the hhvm lexer is or if
we should have yet another language (as I would rather use plain PHP
in this case, even if it makes the task slightly harder to implement
or generate slightly bigger native code due to type checking or
conversions).

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org