No from me as well. This is wagging the dog by the tail. Picking a documentation format is the very least of the concerns here. It would be wonderful to have better internal API documentation, but putting up any sort of structural restriction like limiting it to a specific header-based format, isn't going to make such documentation more likely. I couldn't care less which format such documentation is in. If the folks who are capable of writing decent API docs want to do it in Microsoft Word, LaTeX or some weird SGML format, great! Whatever format it might appear in we can use and convert to whatever makes sense at that point.
-Rasmus On Mon, Jun 26, 2017 at 5:26 AM, Kalle Sommer Nielsen <ka...@php.net> wrote: > HI Joe, > > 2017-06-26 8:43 GMT+02:00 Joe Watkins <pthre...@pthreads.org>: > > Morning, > > > > I also voted no for similar reasons to Anatol. > > > > This is not really a thing that needs a vote, this is a thing that > requires > > the handful of people who are actually able to document ZE to spend > > considerable time doing so. In addition it requires a commitment from the > > community of developers to continue to maintain, and introduce inline > > documentation with new code. > > > > Additionally, I'm a little concerned that an RFC that has the potential > to > > touch every single source file has gone to vote with a simple majority. > It > > would seem that we are deciding that new code must be documented in this > > specific way, to say nothing of the massive task of documenting existing > > code. That would seem to be a decision that could effect everybody that > > works on PHP in perpetuity and a simple majority is nothing like a strong > > enough consensus. > > I'm in the same boat as you and Anatol here. > > I think it is important to note that all who actively work on the > Core/Engine have no except for Stas, which also should be a good > indicator that we should be concerned. > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
