Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106285 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60875 invoked from network); 24 Jul 2019 18:23:00 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 24 Jul 2019 18:23:00 -0000 To: internals@lists.php.net References: Date: Wed, 24 Jul 2019 16:46:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 5.69.56.51 Subject: Re: [PHP-DEV] Re: Generating arginfo from stub files From: markyr@gmail.com (Mark Randall) Message-ID: On 23/07/2019 16:05, Marco Pivetta wrote: > Would it be too aggressive to have (in the php-src test suite, as a first > step) something that ensures that a stub exists for each exposed userland > symbol? That's an interesting point, at the risk of flogging a dead horse with my ignorance of internals, what about using the unit tests as a means of enumerating the arguments, their names and their return types? If there's nothing that meets the requirements of php-src, what about php-src itself? As almost all arg are handled via zpp, and almost all the return values are handled by RETURN_XXX etc, what about a one-off build that modifies those macros to report their usage to a global state, which can be read back after and used to build the docs? Something like a dozen years ago, I wrote a scripting language in C++ for my undergraduate thesis, and hit across a similar problem. I too used macros to define functions arguments, what their types were, copied them into native variables and so forth. When it came to documenting all the functions I was quickly losing my sanity, and so modified my macros so that if ran with a certain define active, they would dump all of their information into a global store that I could dump after. Obviously PHP's use of quasi-overloading doesn't help its situation here, and Z_PARAM_ZVAL and friends could cause quite a headache, as it would need to track what types were extracted through such macros as Z_LVAL_XX. Certainly not a catch-all situation, but might present an opportunity for doing some of the leg work automatically. Mark Randall