Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80381
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain tekwire.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@tekwire.net>
To: "'Sara Golemon'" <pollita@php.net>,
	"'Pierre Joye'" <pierre.php@gmail.com>
Cc: "'Stanislav Malyshev'" <smalyshev@gmail.com>,
	"'PHP internals'" <internals@lists.php.net>
References: <CAESVnVqfoKg=J7BXWf45DFRkEjP9a=TFiDYauD0ZHa-sKXsvDg@mail.gmail.com>	<54B1AA31.6050703@gmail.com>	<CAESVnVrj46bT6niYVaUNf9Cz1xsbjEQ4n5JQAdRY5hmy9hD+SA@mail.gmail.com>	<CAEZPtU69RwqFMOCbkFJkBh-y3RHQpVwi1ES4WkOVGDaneWzMOQ@mail.gmail.com> <CAESVnVrZ76obOSopWU1OyM-iH_W0=Z1OpYuvjJ55BcmmvW+c2w@mail.gmail.com>
In-Reply-To: <CAESVnVrZ76obOSopWU1OyM-iH_W0=Z1OpYuvjJ55BcmmvW+c2w@mail.gmail.com>
Date: Sun, 11 Jan 2015 22:26:55 +0100
Message-ID: <003901d02de5$53732480$fa596d80$@tekwire.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHdpO6kBDBjSAQ05ND+I0bfKmNeFQIeJCUTAflXB0ABzhWVuwG23BUcnGNfIlA=
Content-Language: fr
Subject: RE: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
From: francois@tekwire.net (=?UTF-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : php@golemon.com [mailto:php@golemon.com] De la part de Sara =
Golemon
>
> 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 think it's time to define a scope for a first step, eg rules to know =
if a given if an extension
Is eligible to the tools we are planning in this first step. Some may =
consider it as a waste of time but, when I think we must know where to =
stop before starting anything.

If you agree, I propose this as a base to refine:

- Extension exposes only PHP functions and constants (no OO),
- Each PHP function argument must accept a scalar, an array, or both =
('mixed' case).
- PHP functions return value type can be any scalar type or array.
- one or more PHP function arguments can be optional
- PHP function arguments can be passed by value or by reference.

This constraints should fit a lot of 'bridge-only' extensions. I don't =
include OO because, IMO, storing properties is going too far for a 1st =
step.

I am starting a prototype of an C-code extension generator, written in =
PHP, using high-level function definitions. For each exposed function, =
the high-level definitions mostly define input arguments and return =
value. The generator handles all aspects of argument parsing, going much =
further than the current parsing API. It also handles return values, =
keeps the C code away from zval manipulation.

The implementation will be split between a generic part, which will read =
and format input files in memory, and pluggable generators. Each =
generator will have the responsibility to generate everything needed by =
a specific PHP engine.

For instance, the generator for the PHP interpreter will generate =
everything needed to run phpize/configure/make.

I will tell you when I have a model and examples of metadata definition =
and input files, so that you can tell me if it fits your needs (as I =
don't know HHVM yet).

One more thing : Do you know which existing PECL extension we could use =
for a proof of concept ? This should comply with our scope (basically, =
expose functions and constants only) but a small one would be better. I =
thought about newt but it defines more than 200 functions...

I also realize that this stuff should probably go to an RFC now...

Regards

Fran=C3=A7ois