On Mon, Jan 12, 2015 at 9:29 AM, Sara Golemon <poll...@php.net> wrote:
> On Mon, Jan 12, 2015 at 4:58 AM, François Laupretre
> <franc...@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 = 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,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
