Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80369
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.48 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAEZPtU69RwqFMOCbkFJkBh-y3RHQpVwi1ES4WkOVGDaneWzMOQ@mail.gmail.com>
References: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>
	<54B1AA31.6050703@gmail.com>
	<CAESVnVrj46bT6niYVaUNf9Cz1xsbjEQ4n5JQAdRY5hmy9hD+SA@mail.gmail.com>
	<CAEZPtU69RwqFMOCbkFJkBh-y3RHQpVwi1ES4WkOVGDaneWzMOQ@mail.gmail.com>
Date: Sun, 11 Jan 2015 08:40:14 -0800
Message-ID: <CAESVnVrZ76obOSopWU1OyM-iH_W0=Z1OpYuvjJ55BcmmvW+c2w@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
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: pollita@php.net (Sara Golemon)

On Sat, Jan 10, 2015 at 11:18 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> 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.
>
And this is one of the things I love about HHVM's current extension
API, so yeah I'd like to bring some elements of that in if possible.
At one extreme it means changes to the lexer/parser, and the other end
it might mean a combination of prepend files (which are pure PHP) and
either an interface-definition file (simplified version of PHP) or
something like PHP's current API "inject a function/method here, and
here's the signature".  I imagine this being one of the longer
portions of our discussions since a lot of folks are going to have
opinions on what approach is better.

> 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 :)
>
That's ambitious, but not impossible. :)

> 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).
>
PHP as the greatest-common-denominator makes sense to me too.  Much as
I like the flexibility of user attributes in HHVM, the goal of this
API layer is to be engine agnostic, so syntax should fall into
php-langspec, deviating as little as possible.

-Sara