Re: One API to rule them all? (Was: Extension Prepend Files)

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çois 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 = 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