Re: Proposal to document all of Zend and PHP API and SAPI layers
| From: | Joe Watkins | Date: | Fri, 05 Apr 2013 21:44:21 +0000 |
| Subject: | Re: Proposal to document all of Zend and PHP API and SAPI layers | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-66992@lists.php.net to get a copy of this message | ||
On 04/05/2013 12:00 PM, Joe Watkins wrote:
Morning All,There seems to be a kind of focus on the things we all know about, understandably. To clarify, I do not mean that we should document hashtable and objects and call it a day, I mean that there is more than 1000 exported ZEND_API or PHPAPI functions in the source code this evening ... here's a list: http://pastebin.com/42xFsNQ0 Drop the scrollbar anywhere random, have you written what you land on more than once ?? Think it's probably worth the time now ?? Surely writing extensions and developing patches and ideas would become much easier if this knowledge was easily accessible and documented, surely you'll get the time back you put in 10 fold ?? Food for thought .... Nite ...Further to discussion in IRC this morning, I'd like to propose whatamounts to, I guess, a sub-project to properly document everything, starting with everything declared ZEND_API in /Zend.We put a lot of effort into the generation and maintenance of userland documentation, but there are only scraps of information here and there, and then ... the accepted way of working with the source is lxr and lots and lots of reading, which is fine, if you require intricate knowledge of every part of the API you are interacting with, which normally you do not, usually it is enough to know of it's existence, it's usage and implementation is either obvious or irrelevant in the vast majority of cases, should the function prototype be documented.I am also aware of some documentation included in the PHP manualcurrently, which should also be completed, and included, with all of the API in a searchable format, just like PHP is in userland.Ideally, it would be nice to document the API inline, in source,this means disturbing lots of files, which I'm not keen on, if anyone has any ideas, speak up. The benefit of inline documentation is that if a function is changed the changer has the documentation in their peripheral vision, and the chances of documentation getting stale are less likely than if they have to document using some separate system.I'd like to gauge reaction to this idea, and with it a show ofhands, who can actually help ?? Thanks for listening :) Joe