Documenting the Zend2 extension API

php.internals

Gwynne Raskind

19 years ago
Given the recent discussion of the lack of real documentation for the Zend API, and the endless links provided to various sources of usually incomplete information, I thought it might be a good idea if someone wrote an actual book on the subject. I'm interested in taking that project upon myself, and I'm wondering what advice anyone has to offer on the idea. -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable."

Derick Rethans

19 years ago
On Wed, 25 Apr 2007, Gwynne Raskind wrote:
> Given the recent discussion of the lack of real documentation for the Zend > API, and the endless links provided to various sources of usually incomplete > information, I thought it might be a good idea if someone wrote an actual book > on the subject. I'm interested in taking that project upon myself, and I'm > wondering what advice anyone has to offer on the idea.
There is one: http://www.amazon.com/Extending-Embedding-PHP-Developers-Library/dp/067232704X/ref=sr_1_1/102-2890754-1426549?ie=UTF8&s=books&qid=1177529537&sr=8-1 regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Gwynne Raskind

19 years ago
On Apr 25, 2007, at 3:33 PM, Derick Rethans wrote:
>> Given the recent discussion of the lack of real documentation for >> the Zend >> API, and the endless links provided to various sources of usually >> incomplete >> information, I thought it might be a good idea if someone wrote an >> actual book >> on the subject. I'm interested in taking that project upon myself, >> and I'm >> wondering what advice anyone has to offer on the idea. > There is one: > http://www.amazon.com/Extending-Embedding-PHP-Developers-Library/dp/ > 067232704X/ref=sr_1_1/102-2890754-1426549? > ie=UTF8&s=books&qid=1177529537&sr=8-1
Hmm... For some reason I missed that in my searches. That being said, the existence of one doesn't preclude the writing of another :). Also, it seems the official documentation in the PHP manual could use some serious updating, which I would also be willing to undertake if people think that would be more useful. -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable."

Antony Dovgal

19 years ago
On 04/26/2007 01:45 AM, Gwynne Raskind wrote:
> Hmm... For some reason I missed that in my searches. That being said, > the existence of one doesn't preclude the writing of another :). > Also, it seems the official documentation in the PHP manual could use > some serious updating, which I would also be willing to undertake if > people think that would be more useful.
Actually I've been recently thinking of adding some kind of documentation to the sources. Surely this is not supposed to be something similar to php.net/manual/, just short descriptions of functions and their arguments, which can be used as a start for the "real" documentation. But I wasn't lucky enough to find a utility that would fit my (personal) needs. Doxygen (which seems to be uses by the majority of F/OSS projects) generates completely unreadable docs. Every time I look into ICU docs (generated by Doxygen) I get lost for 10 minutes trying to find a function _by name_. In the same time, other tools do not provide such a wide range of output formats as available in Doxygen. Anyways ZE internals documentation definitely needs serious update and this would be very much appreciated. The only problem is that you need to know the internals a bit (or at least want to learn it) to be able to document it, and all the people with this knowledge are busy with other things most of the time.. You can count on me if you need any help/hints, though.
-- Wbr, Antony Dovgal

Marcus Börger

19 years ago
Hello Antony, Thursday, April 26, 2007, 12:05:07 AM, you wrote:
> On 04/26/2007 01:45 AM, Gwynne Raskind wrote: >> Hmm... For some reason I missed that in my searches. That being said, >> the existence of one doesn't preclude the writing of another :). >> Also, it seems the official documentation in the PHP manual could use >> some serious updating, which I would also be willing to undertake if >> people think that would be more useful.
> Actually I've been recently thinking of adding some kind of documentation to the sources. > Surely this is not supposed to be something similar to php.net/manual/, just short > descriptions of functions and their arguments, which can be used as a start for the "real" > documentation. > But I wasn't lucky enough to find a utility that would fit my (personal) needs.
> Doxygen (which seems to be uses by the majority of F/OSS projects) > generates completely unreadable docs. > Every time I look into ICU docs (generated by Doxygen) I get lost for 10 > minutes trying to find a function _by name_. > In the same time, other tools do not provide such a wide range of output formats as available in Doxygen.
Hu? It has a search option if you want. And it has alphabetical lists for functions, consts, classes, files, modules, whatever. And if that is not enough we could take it's xml output to feed a database and provide a fulltext search on that.
> Anyways ZE internals documentation definitely needs serious update and this would be very much appreciated. > The only problem is that you need to know the internals a bit (or at least want to learn it) to be > able to document it, and all the people with this knowledge are busy with other things most of the time.. > You can count on me if you need any help/hints, though.
> -- > Wbr, > Antony Dovgal
Best regards, Marcus

Antony Dovgal

19 years ago
On 04/26/2007 02:12 AM, Marcus Boerger wrote:
>> Doxygen (which seems to be uses by the majority of F/OSS projects) >> generates completely unreadable docs. >> Every time I look into ICU docs (generated by Doxygen) I get lost for 10 >> minutes trying to find a function _by name_. >> In the same time, other tools do not provide such a wide range of output formats as available in Doxygen. > > Hu? It has a search option if you want.
This one? =) http://www.icu-project.org/apiref/icu4c/search.php?query=strcat
> And it has alphabetical lists for > functions, consts, classes, files, modules, whatever.
Maybe there is something wrong with ICU docs (or with me?), but I can't find any alphabetical index of functions. All I can see is a list of functions per file, which is noway convenient.
> And if that is not enough we could take it's xml output to feed a database and provide a > fulltext search on that.
We can also use any of search engines available to search in the result HTML. But the point is that the docs should be well structured enough so that a fulltext search would not be required.
-- Wbr, Antony Dovgal

Marcus Börger

19 years ago
Hello Antony, Thursday, April 26, 2007, 12:25:30 AM, you wrote:
> On 04/26/2007 02:12 AM, Marcus Boerger wrote: >>> Doxygen (which seems to be uses by the majority of F/OSS projects) >>> generates completely unreadable docs. >>> Every time I look into ICU docs (generated by Doxygen) I get lost for 10 >>> minutes trying to find a function _by name_. >>> In the same time, other tools do not provide such a wide range of output formats as available in Doxygen. >> >> Hu? It has a search option if you want.
> This one? =) > http://www.icu-project.org/apiref/icu4c/search.php?query=strcat
>> And it has alphabetical lists for >> functions, consts, classes, files, modules, whatever.
> Maybe there is something wrong with ICU docs (or with me?), but I can't > find any alphabetical index of functions. > All I can see is a list of functions per file, which is noway convenient.
Go to: http://www.php.net/~helly/php/ext/spl/ On the left select 'file members' Then on the top of the main part select 'functions' That will give you all global functions. Now, open 'Class Members' on the left Then on the top of the main part select 'functions' That will give you a list of all functions, each with a list of classes/interfaces implementing them
>> And if that is not enough we could take it's xml output to feed a database and provide a >> fulltext search on that.
> We can also use any of search engines available to search in the result HTML. > But the point is that the docs should be well structured enough so that a > fulltext search would not be required.
As i said, from doxygen' XML output we can generate any kind of structure we see fit. best regards marcus

Antony Dovgal

19 years ago
On 04/26/2007 09:47 PM, Marcus Boerger wrote:
> Hello Antony, > > Thursday, April 26, 2007, 12:25:30 AM, you wrote: > >> On 04/26/2007 02:12 AM, Marcus Boerger wrote: >>>> Doxygen (which seems to be uses by the majority of F/OSS projects) >>>> generates completely unreadable docs. >>>> Every time I look into ICU docs (generated by Doxygen) I get lost for 10 >>>> minutes trying to find a function _by name_. >>>> In the same time, other tools do not provide such a wide range of output formats as available in Doxygen. >>> >>> Hu? It has a search option if you want. > >> This one? =) >> http://www.icu-project.org/apiref/icu4c/search.php?query=strcat > >>> And it has alphabetical lists for >>> functions, consts, classes, files, modules, whatever. > >> Maybe there is something wrong with ICU docs (or with me?), but I can't >> find any alphabetical index of functions. >> All I can see is a list of functions per file, which is noway convenient. > > Go to: http://www.php.net/~helly/php/ext/spl/ > On the left select 'file members' > Then on the top of the main part select 'functions' > That will give you all global functions.
You really think this is good structure?
> Now, open 'Class Members' on the left > Then on the top of the main part select 'functions' > That will give you a list of all functions, > each with a list of classes/interfaces implementing them
4 clicks just to get to the list of functions? No, doxygen is definitely not what I would like to use.
>>> And if that is not enough we could take it's xml output to feed a database and provide a >>> fulltext search on that. > >> We can also use any of search engines available to search in the result HTML. >> But the point is that the docs should be well structured enough so that a >> fulltext search would not be required. > > As i said, from doxygen' XML output we can generate any kind of > structure we see fit.
-- Wbr, Antony Dovgal

Derick Rethans

19 years ago
On Thu, 26 Apr 2007, Marcus Boerger wrote:
> Hello Antony, > > Thursday, April 26, 2007, 12:05:07 AM, you wrote: > > > On 04/26/2007 01:45 AM, Gwynne Raskind wrote: > >> Hmm... For some reason I missed that in my searches. That being > >> said, the existence of one doesn't preclude the writing of another > >> :). Also, it seems the official documentation in the PHP manual > >> could use some serious updating, which I would also be willing to > >> undertake if people think that would be more useful. > > > Actually I've been recently thinking of adding some kind of > > documentation to the sources. Surely this is not supposed to be > > something similar to php.net/manual/, just short descriptions of > > functions and their arguments, which can be used as a start for the > > "real" documentation. But I wasn't lucky enough to find a utility > > that would fit my (personal) needs. > > > Doxygen (which seems to be uses by the majority of F/OSS projects) > > generates completely unreadable docs. Every time I look into ICU > > docs (generated by Doxygen) I get lost for 10 minutes trying to find > > a function _by name_. In the same time, other tools do not provide > > such a wide range of output formats as available in Doxygen. > > Hu? It has a search option if you want. And it has alphabetical lists > for functions, consts, classes, files, modules, whatever. And if that > is not enough we could take it's xml output to feed a database and > provide a fulltext search on that.
That doesn't make the docs more readable though... Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Gwynne Raskind

19 years ago
On Apr 25, 2007, at 6:05 PM, Antony Dovgal wrote:
>> Hmm... For some reason I missed that in my searches. That being >> said, the existence of one doesn't preclude the writing of >> another :). Also, it seems the official documentation in the PHP >> manual could use some serious updating, which I would also be >> willing to undertake if people think that would be more useful. > Actually I've been recently thinking of adding some kind of > documentation to the sources. > Surely this is not supposed to be something similar to php.net/ > manual/, just short descriptions of functions and their arguments, > which can be used as a start for the "real" documentation. > But I wasn't lucky enough to find a utility that would fit my > (personal) needs. > > Doxygen (which seems to be uses by the majority of F/OSS projects) > generates completely unreadable docs. > Every time I look into ICU docs (generated by Doxygen) I get lost > for 10 minutes trying to find a function _by name_. > In the same time, other tools do not provide such a wide range of > output formats as available in Doxygen. > > Anyways ZE internals documentation definitely needs serious update > and this would be very much appreciated. > The only problem is that you need to know the internals a bit (or > at least want to learn it) to be able to document it, and all the > people with this knowledge are busy with other things most of the > time.. > You can count on me if you need any help/hints, though.
I've been plugging around writing extensions long enough to have some idea of the internals; more than once I've answered a question by digging through the Zend sources for the internals of some API. I'm willing to at least take a crack at this project; the worst I can do is fail :). Would it make sense to ask for CVS karma on the docs now or wait a bit? -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable."

Antony Dovgal

19 years ago
On 04/26/2007 02:32 AM, Gwynne Raskind wrote:
> I've been plugging around writing extensions long enough to have some > idea of the internals; more than once I've answered a question by > digging through the Zend sources for the internals of some API.
Great!
> I'm willing to at least take a crack at this project; the worst I can do > is fail :). Would it make sense to ask for CVS karma on the docs now > or wait a bit?
I believe the best way to get karma is to start sending patches. I would also recommend to establish the build environment for the docs (if you don't have one already), it's good idea to test patches before committing. This document should give you a good start: http://doc.php.net/php/dochowto/index.php
-- Wbr, Antony Dovgal

Steph

19 years ago
- and that will teach me to read to the end of the thread before I respond. What Tony said :) ----- Original Message ----- From: "Antony Dovgal" <antony@zend.com> To: "Gwynne Raskind" <gwynne@wanderingknights.org> Cc: <internals@lists.php.net> Sent: Wednesday, April 25, 2007 11:51 PM Subject: Re: [PHP-DEV] Documenting the Zend2 extension API

Gwynne Raskind

19 years ago
On Apr 25, 2007, at 6:51 PM, Antony Dovgal wrote:
>> I've been plugging around writing extensions long enough to have >> some idea of the internals; more than once I've answered a >> question by digging through the Zend sources for the internals of >> some API. > Great! >> I'm willing to at least take a crack at this project; the worst I >> can do is fail :). Would it make sense to ask for CVS karma on >> the docs now or wait a bit? > I believe the best way to get karma is to start sending patches. > > I would also recommend to establish the build environment for the > docs (if you don't have one already), it's good idea to test > patches before committing. > This document should give you a good start: http://doc.php.net/php/ > dochowto/index.php
Hi all, just wanted to give you a heads-up that I'm still working on this project; it took me awhile to get the tools properly set up, but I'm plugging away at DocBook XML now, and I'll have a few patches to send in soon, I think. Thanks for all the advice so far! -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable."

Philip Olson

19 years ago
On May 5, 2007, at 6:47 PM, Gwynne Raskind wrote:
> On Apr 25, 2007, at 6:51 PM, Antony Dovgal wrote: >>> I've been plugging around writing extensions long enough to have >>> some idea of the internals; more than once I've answered a >>> question by digging through the Zend sources for the internals >>> of some API. >> Great! >>> I'm willing to at least take a crack at this project; the worst >>> I can do is fail :). Would it make sense to ask for CVS karma on >>> the docs now or wait a bit? >> I believe the best way to get karma is to start sending patches. >> >> I would also recommend to establish the build environment for the >> docs (if you don't have one already), it's good idea to test >> patches before committing. >> This document should give you a good start: http://doc.php.net/php/ >> dochowto/index.php > > Hi all, just wanted to give you a heads-up that I'm still working > on this project; it took me awhile to get the tools properly set > up, but I'm plugging away at DocBook XML now, and I'll have a few > patches to send in soon, I think. Thanks for all the advice so far!
Hello Gwynne, This is excellent news, and feel free to write the doc list if you have any questions and/or the IRC channels on efnet (#php.pecl and #php.doc). As far as information on the topic goes, let's start a list of the current landscape (with ideas to steal from): - The official docs: http://php.net/manual/internals - CodeGen_PECL: http://pear.php.net/package/codegen_pecl - A few tutorials: http://devzone.zend.com/public/view/tag/extension - The book: Extending and Embedding PHP by Sara Golemon - Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/ - A few talks: http://talks.php.net/index.php/Internals - A nice talk: http://netevil.org/talks/furlong-golemon-extending- php.pdf - More talks: http://talks.somabo.de/ - A nice talk: http://talks.somabo.de/ 200610_zend_conf_php_extension_development.pdf - A few examples: http://people.apache.org/~nabeel/php/examples/ Also, let's create a FAQ section dedicated to the topic of extension writing. Regards, Philip

Gwynne Raskind

19 years ago
On May 8, 2007, at 2:59 PM, Philip Olson wrote:
>> Hi all, just wanted to give you a heads-up that I'm still working >> on this project; it took me awhile to get the tools properly set >> up, but I'm plugging away at DocBook XML now, and I'll have a few >> patches to send in soon, I think. Thanks for all the advice so far! > Hello Gwynne, > > This is excellent news, and feel free to write the doc list if you > have any questions and/or the IRC channels on efnet (#php.pecl and > #php.doc). As far as information on the topic goes, let's start a > list of the current landscape (with ideas to steal from): > > - The official docs: http://php.net/manual/internals > - CodeGen_PECL: http://pear.php.net/package/codegen_pecl > - A few tutorials: http://devzone.zend.com/public/view/tag/extension > - The book: Extending and Embedding PHP by Sara Golemon > - Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/ > - A few talks: http://talks.php.net/index.php/Internals > - A nice talk: http://netevil.org/talks/furlong-golemon-extending- > php.pdf > - More talks: http://talks.somabo.de/ > - A nice talk: http://talks.somabo.de/ > 200610_zend_conf_php_extension_development.pdf > - A few examples: http://people.apache.org/~nabeel/php/examples/ > > Also, let's create a FAQ section dedicated to the topic of > extension writing.
This list of links has been extremely helpful to me, Philip; I appreciate it a lot :). I'm embarassed to say I came down with a bit of writer's block lately, so I don't have any patches to send in yet, unfortunately. However, I would like the opinion of the list on the avenue I've chosen. Basically, it's my estimation that the existing internals documentation in the manual is not organized very well, nor lends itself to updating with any manner of ease. The material I've been writing is a new section dedicated to the API of ZE2, rather than trying to consolidate all the information for ZE1 (outdated) and ZE3 (still changing almost every day). My preliminary outline for the content looks like this (yanked out of my diffs for manual.xml.in and subject to change): <part id="internals2"> <title>&Internals2;</title> &internals2.intro; &internals2.buildsys.index; <!-- configure options, ext_skel, config.m4, config.w32, static vs dynamic builds --> &internals2.structure.index; <!-- ext_skel, module structure, globals, lifecycle, tests --> &internals2.memory.index; <!-- management, persistence, TSRM --> &internals2.variables.index; <!-- zval, hashtable, references, constants --> &internals2.functions.index; <!-- defining, arguments, return values, passthru, aliasing --> &internals2.objects.index; <!-- classes, inheritance, properties, methods, method-function mapping --> &internals2.resources.index; <!-- defining, creating, retrieving, destroying --> &internals2.ini.index; <!-- defining, retrieving, changing --> &internals2.streams.index; <!-- using, wrappers, contexts, filters --> <!-- grab the PDO section from &Internals; here? --> &internals2.apiref.index; <!-- full index of all APIs, constants, macros, etc. --> &internals2.ze1.index; <!-- quick list of major differences, short discussion re: OOP --> &internals2.ze3.index; <!-- quick discussion of major changes, some details on Unicode --> </part> My thinking is to document ZE2 completely, since the differences between 1 and 2 are small enough for the existing internals section to be of use to anyone writing for 1, and 3 can be more fully documented later (something I'm willing to take on as well). If I'm given a thumbs-down on this way of doing things, I'll take the material I've written already and use it to update the existing internals section, but I think this method has the best chance of giving people the truly comprehensive online reference we've lacked for extension writing up to this point. -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable."

Gwynne Raskind

19 years ago
On May 8, 2007, at 2:59 PM, Philip Olson wrote:
>> Hi all, just wanted to give you a heads-up that I'm still working >> on this project; it took me awhile to get the tools properly set >> up, but I'm plugging away at DocBook XML now, and I'll have a few >> patches to send in soon, I think. Thanks for all the advice so far! > Hello Gwynne, > > This is excellent news, and feel free to write the doc list if you > have any questions and/or the IRC channels on efnet (#php.pecl and > #php.doc). As far as information on the topic goes, let's start a > list of the current landscape (with ideas to steal from): > > - The official docs: http://php.net/manual/internals > - CodeGen_PECL: http://pear.php.net/package/codegen_pecl > - A few tutorials: http://devzone.zend.com/public/view/tag/extension > - The book: Extending and Embedding PHP by Sara Golemon > - Many README files in php-src: http://cvs.php.net/viewvc.cgi/php-src/ > - A few talks: http://talks.php.net/index.php/Internals > - A nice talk: http://netevil.org/talks/furlong-golemon-extending- > php.pdf > - More talks: http://talks.somabo.de/ > - A nice talk: http://talks.somabo.de/ > 200610_zend_conf_php_extension_development.pdf > - A few examples: http://people.apache.org/~nabeel/php/examples/ > > Also, let's create a FAQ section dedicated to the topic of > extension writing.
This list of links has been extremely helpful to me, Philip; I appreciate it a lot :). I'm embarassed to say I came down with a bit of writer's block lately, so I don't have any patches to send in yet, unfortunately. However, I would like the opinion of the list on the avenue I've chosen. Basically, it's my estimation that the existing internals documentation in the manual is not organized very well, nor lends itself to updating with any manner of ease. The material I've been writing is a new section dedicated to the API of ZE2, rather than trying to consolidate all the information for ZE1 (outdated) and ZE3 (still changing almost every day). My preliminary outline for the content looks like this (yanked out of my diffs for manual.xml.in and subject to change): <part id="internals2"> <title>&Internals2;</title> &internals2.intro; &internals2.buildsys.index; <!-- configure options, ext_skel, config.m4, config.w32, static vs dynamic builds --> &internals2.structure.index; <!-- ext_skel, module structure, globals, lifecycle, tests --> &internals2.memory.index; <!-- management, persistence, TSRM --> &internals2.variables.index; <!-- zval, hashtable, references, constants --> &internals2.functions.index; <!-- defining, arguments, return values, passthru, aliasing --> &internals2.objects.index; <!-- classes, inheritance, properties, methods, method-function mapping --> &internals2.resources.index; <!-- defining, creating, retrieving, destroying --> &internals2.ini.index; <!-- defining, retrieving, changing --> &internals2.streams.index; <!-- using, wrappers, contexts, filters --> <!-- grab the PDO section from &Internals; here? --> &internals2.apiref.index; <!-- full index of all APIs, constants, macros, etc. --> &internals2.ze1.index; <!-- quick list of major differences, short discussion re: OOP --> &internals2.ze3.index; <!-- quick discussion of major changes, some details on Unicode --> </part> My thinking is to document ZE2 completely, since the differences between 1 and 2 are small enough for the existing internals section to be of use to anyone writing for 1, and 3 can be more fully documented later (something I'm willing to take on as well). If I'm given a thumbs-down on this way of doing things, I'll take the material I've written already and use it to update the existing internals section, but I think this method has the best chance of giving people the truly comprehensive online reference we've lacked for extension writing up to this point. -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable."

LAUPRETRE François (P)

19 years ago
Hello Gwynne, A suggestion: please add something about exceptions, creating and throwing them, implementing try/catch blocks. I was looking for a way to catch exceptions thrown by some userspace code, and I didn't find anything except the PHP source. Best regards Francois

Philip Olson

19 years ago
> > <part id="internals2"> > <title>&Internals2;</title> > &internals2.intro; > &internals2.buildsys.index; <!-- configure options, ext_skel, > config.m4, config.w32, static vs dynamic builds --> > &internals2.structure.index; <!-- ext_skel, module structure, > globals, lifecycle, tests --> > &internals2.memory.index; <!-- management, persistence, TSRM --> > &internals2.variables.index; <!-- zval, hashtable, references, > constants --> > &internals2.functions.index; <!-- defining, arguments, return > values, passthru, aliasing --> > &internals2.objects.index; <!-- classes, inheritance, > properties, methods, method-function mapping --> > &internals2.resources.index; <!-- defining, creating, > retrieving, destroying --> > &internals2.ini.index; <!-- defining, retrieving, changing > --> > &internals2.streams.index; <!-- using, wrappers, contexts, > filters --> > <!-- grab the PDO section from &Internals; here? --> > &internals2.apiref.index; <!-- full index of all APIs, > constants, macros, etc. --> > &internals2.ze1.index; <!-- quick list of major > differences, short discussion re: OOP --> > &internals2.ze3.index; <!-- quick discussion of major > changes, some details on Unicode --> > </part> > > My thinking is to document ZE2 completely, since the differences > between 1 and 2 are small enough for the existing internals section > to be of use to anyone writing for 1, and 3 can be more fully > documented later (something I'm willing to take on as well). > > If I'm given a thumbs-down on this way of doing things, I'll take > the material I've written already and use it to update the existing > internals section, but I think this method has the best chance of > giving people the truly comprehensive online reference we've lacked > for extension writing up to this point.
Hello Gwynne, Sounds good. Many times silence on this list means "Sounds good" and internals isn't too keen on defining a structure for documentation... :) So, go for it! Always feel free to ask questions while documenting this and as it all progresses let's be sure internals reviews the information too. Once the information is in manageable and smaller pieces you'll likely have more success getting feedback. And don't be a stranger on #php.pecl @ efnet (IRC) either. Regards, Philip

Stanislav Malyshev

19 years ago
> Doxygen (which seems to be uses by the majority of F/OSS projects) > generates completely unreadable docs. > Every time I look into ICU docs (generated by Doxygen) I get lost for 10 > minutes trying to find a function _by name_.
Well, in ICU there are two sets of docs - the automatic docs (e.g. http://www.icu-project.org/apiref/icu4c/unum_8h.html) and the human docs (e.g. http://icu-project.org/userguide/formatNumbers.html). Ideally, we should have both - the former is for checking the API, the latter is for actually understanding what it does. There's no way to get the latter doc except for actual person to write it. :)
> The only problem is that you need to know the internals a bit (or at > least want to learn it) to be able to document it, and all the people > with this knowledge are busy with other things most of the time.. > You can count on me if you need any help/hints, though.
Same here.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Wez Furlong

19 years ago
We use doxygen for the developer portions of our customer facing manual. The trick is to have it output xml and then massage that to fit into docbook. --Wez. On 4/25/07, Antony Dovgal <antony@zend.com> wrote:

Steph

19 years ago
Gwynne, I'm not wanting to be nasty or anything, but: a) Sara is totally expert in this area and you, as yet, are not b) the reason that was ever needed at all is that the open source stuff needs work. If you really want to make things easier for incomers, work on the open source documentation on php.net. Please. It needs serious attention. If you just want glorification, forget it - one with far stronger credentials has gone before. - Steph ----- Original Message ----- From: "Gwynne Raskind" <gwynne@wanderingknights.org> To: <internals@lists.php.net> Sent: Wednesday, April 25, 2007 10:45 PM Subject: Re: [PHP-DEV] Documenting the Zend2 extension API