Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80428
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVqCYzMw_Jxum_EO48QEO6C-9WtKxjuYU6dECOTbFJxn_w@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>
	<CAESVnVrZ76obOSopWU1OyM-iH_W0=Z1OpYuvjJ55BcmmvW+c2w@mail.gmail.com>
	<003901d02de5$53732480$fa596d80$@tekwire.net>
	<005a01d02e1a$02d27a00$08776e00$@tekwire.net>
	<CAESVnVrS9WpS-rUxZ46Mjjocb8K_ZrG6Jb5qaPPqGRWfEn+0Eg@mail.gmail.com>
	<008f01d02e67$6e92ad80$4bb80880$@tekwire.net>
	<CAESVnVqCYzMw_Jxum_EO48QEO6C-9WtKxjuYU6dECOTbFJxn_w@mail.gmail.com>
Date: Mon, 12 Jan 2015 18:02:30 -0800
Message-ID: <CAEZPtU535AtA3O52jwK5oUpM7saFzHNtnESyK=iNVf77droZcA@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Jan 12, 2015 at 9:29 AM, Sara Golemon <pollita@php.net> wrote:
> On Mon, Jan 12, 2015 at 4:58 AM, Fran=C3=A7ois Laupretre
> <francois@tekwire.net> wrote:
>> I am not crazy about it either, I just want to generate code for
>> argument parsing (removing every access to zval, dealing with
>> 'mixed' type, checks...), return value (convert to zval, maybe a
>> pair of checks), and the global 'glue' code (global header file,
>> function/constant declare/undeclare, all the boring stuff).
>> Some of this is too complex for C macros. The rest is provided
>> by the user in C and stays in C. This code will use C macros to
>> access what we want to abstract.
>>
> Okay, but why even generate code for argument parsing? Why not just
> pass the arguments/return-values as their concrete type?
>
> For the record, I'm with you on not having anyone access zvals
> directly, or having them deal with zpp, but that doesn't necessitate
> generated code.
>
>> PHP is fine but defining a tree of metadata in json or yaml is
>> really easier than writing nested array statements.
>>
> Could you explain what you mean by this?  I'm not sure where nested
> arrays come from.
>
> For example, the PHP code could be something as simple as the
> following (but see below, I don't think this is necessarily a good
> idea):
>
> function NATIVE_STRING_foo(int $bar, float $baz =3D 3.14) {}
>
> Although scalar type hints aren't supported, we can actually fake them
> in the parser letting them look like class type hints, then converting
> them post-parse.  Meanwhile, a function with an empty body named
> "NATIVE_T_*()" indicates its a stub, and what type it returns.  Ugly,
> yes.  But compatible with all PHP parsers 5 and later.
>
> Then in the C/C++ side, we present:
>
> php_string foo(int bar, double baz) {
>   /* Normal(ish) C code goes here */
> }

I must be something but I do not know how it can be exposed to
userland like that without the execute_data part.

By the way, we may finally have a good usage for the new args macros ;)

> All that said, I think we can do better than fake typehints and a
> kludgy return type, but my point is that we don't need to invent a new
> format just to declare functions since we had this nice language
> called PHP which already knows what PHP functions look like.

Yes, only not sure we can do it for 5.x and 7.x. I mean the native
parts, if we manage to provide new APIs (maybe backport could be
allowed or via an "extension" that simply gets bundled).

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org