Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84343
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Message-ID: <54F87394.6080501@gmail.com>
Date: Thu, 05 Mar 2015 15:17:40 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <002701d0574a$83ab4360$8b01ca20$@tutteli.ch>
In-Reply-To: <002701d0574a$83ab4360$8b01ca20$@tutteli.ch>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] function signatures in XML
From: rowan.collins@gmail.com (Rowan Collins)

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]