Re: looking for volunteers phpDocumentor, new converter reST

> I'll admit I didn't read this thread until the parent post to your > post. But settling on a documentation standard that requires using a > tool that is only written for another scripting language seems > downright silly to me. Thats like running php.net off of mod_perl > because you want to use some of the api hooking features available > there and not in php. > > Now I understand that translators do not format a format constitute. I > also believe that forcing use of Python/Perl as part of any central PHP > management process is sad, ironic, and self-defeating. Even when this > arrangement is forced onto you by it being the defacto choice available > for a problem. Well, the solution is not to continue using docbook, which is extremely hard to write for and makes documentation extremely painful (and sparse). From a pragmatic standpoint, we can use Python for now, and if someone is deeply saddened by that requirement they can rewrite the python code to php. There is so much stuff to get done, and so little time. I hardly see the need to use one language for everything, when perfectly good tools are available, but written in another language. We're not bundling the python program, just requiring that its installed on your system, or installed on the main pear system. Its not writing the pear command in python, its just requiring a program that was written using python. If that insults people's sensibilities, I'm sure everyone for the usage of ReST would be happy for a version of the program written in PHP. But let's not create work for purity's sake. -Sterling PS: The mod_perl analogy is flawed. A better example is that we call out to a Perl program, like htdig to index our PHP site, because we don't want to rewrite the indexer in PHP itself. You gotta use the right tool for the job Beavis :) -- "First they ignore you, then they laugh at you, then they fight you, then you win." - Gandhi