Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105975 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42148 invoked from network); 18 Jun 2019 21:23:21 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 18 Jun 2019 21:23:21 -0000 To: internals@lists.php.net References: Date: Tue, 18 Jun 2019 19:37:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 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: 94.1.167.52 Subject: Re: [PHP-DEV] Generating arginfo from stub files From: markyr@gmail.com (Mark Randall) Message-ID: On 18/06/2019 18:53, Nikita Popov wrote: > This is not really possible, because we need completely accurate type > information. phpstorm-stubs is a good approximation especially when it > comes to "useful" return types, but it doesn't model things like possible > "false" return values with sufficient accuracy. Any type information we add > in php-src needs a careful review against the implementation. I say this with a certain amount of ignorance, but what about the existing manual? As the authoritative source of user-facing documentation, does it not contain an XML parseable signature for every method, in addition to a return value section detailing types and a standard boilerplate for things with falseable return values? The main issue I would see is "mixed" argument types in the signature which would require manual intervention. I'd certainly like to see a more comprehensive format. Stubs are great but stubs seem more like the end result rather than the original metadata. An XML or JSON file capable of expressing the names, types, defaults etc would have the added benefit of being easily extensible to cover things like descriptions or unions with different requirements for each type. Well-docblock'd stubs, C definitions, documentation pages etc would then be the drawn from the JSON rather than the other way. -- Mark Randall