Re: function signatures in XML
| From: | Rowan Collins | Date: | Thu, 05 Mar 2015 15:17:40 +0000 |
| Subject: | Re: function signatures in XML | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-84343@lists.php.net to get a copy of this message | ||
Robert Stoll wrote on 05/03/2015 13:44:
Heya, Does PHP store somewhere meta-information of all internal functions (and operators) in a portable format such as XML? I would like to extract information such as - parameters including types - return type automatically. Preferably each overload of a function but I guess that does not exist. For instance, str_replace has overloads: string x string x string x (&int) -> string string x string x array x (&int) -> array array x string x string x (&int) -> string array x array x string x (&int) -> string array x array x array x (&int) -> array Unfortunately, the manual as such is not precise enough for my needs.I'm not an expert, so can't give a final answer, but a couple of bits I've picked up from lurking for the last few months and digging into the source out of curiosity: - The manual entries for new extensions are actually built using Reflection, with a script called "docgen" here: http://svn.php.net/viewvc/phpdoc/doc-base/trunk/scripts/docgen/ - I believe the reflection in turn comes from the "ARG_INFO" macros, e.g. http://lxr.php.net/xref/PHP_TRUNK/ext/standard/basic_functions.c#2332 - The overloads you mention aren't (in most cases) really overloads, the C functions parse arguments using a bunch of macros referred to as "ZPP", and can do various things with them, including just accepting a zval (i.e. parameter of any type) and interrogating that C structure to see what type it is. For instance, str_replace does that here: http://lxr.php.net/xref/PHP_TRUNK/ext/standard/string.c#4130 - As far as I know, the return type isn't declared anywhere, it's just an output parameter which points at a zval, and the code can set it to whatever it wants. I may be missing something there though. As you can see, the arg_info just has the parameter names and by-ref flag, and in the definition itself there's just a bunch of code branches for "if (Z_TYPE_P(search) != IS_ARRAY)", "if (Z_TYPE_P(replace) != IS_STRING)", etc, so there's no way of recovering a table of valid type combinations like that without a LOT of code analysis. This is one of the things that makes consistency difficult with scalar type hinting - internal functions, although written in a strictly typed language, aren't actually type hinted! Regards, -- Rowan Collins [IMSoP]