Re: function signatures in XML

From: 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]

« previous php.internals (#84343) next »