Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80419
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.217.175 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <008f01d02e67$6e92ad80$4bb80880$@tekwire.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>
	<003901d02de5$53732480$fa596d80$@tekwire.net>
	<005a01d02e1a$02d27a00$08776e00$@tekwire.net>
	<CAESVnVrS9WpS-rUxZ46Mjjocb8K_ZrG6Jb5qaPPqGRWfEn+0Eg@mail.gmail.com>
	<008f01d02e67$6e92ad80$4bb80880$@tekwire.net>
Date: Mon, 12 Jan 2015 09:29:50 -0800
Message-ID: <CAESVnVqCYzMw_Jxum_EO48QEO6C-9WtKxjuYU6dECOTbFJxn_w@mail.gmail.com>
To: francois@tekwire.net
Cc: Pierre Joye <pierre.php@gmail.com>, 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: pollita@php.net (Sara Golemon)

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 */
}

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.

-Sara