Req #72334 [NEW]: Link(s) to view the relevant PHP C source code in the documentation
| From: | webmaster_20160604 at cubiclesoft dot com | Date: | Sat, 04 Jun 2016 15:56:41 +0000 |
| Subject: | Req #72334 [NEW]: Link(s) to view the relevant PHP C source code in the documentation | ||
| Groups: | php.doc.bugs | ||
| Request: | Send a blank email to doc-bugs+get-13486@lists.php.net to get a copy of this message | ||
From: webmaster_20160604 at cubiclesoft dot com
Operating system: N/A
PHP version: Irrelevant
Package: Documentation problem
Bug Type: Feature/Change Request
Bug description:Link(s) to view the relevant PHP C source code in the documentation
Description:
------------
One of the greatest sources of frustration in PHP is the disconnect
between the documentation and the actual C source code. I personally
keep a copy of the PHP C source code handy for searching purposes but I
know I'm in the minority and, even then, I rarely crack it open because
doing so requires overcoming certain mental inertia. I also have
observed a general disdain of PHP userland developers on the internals
list because userland devs don't look at/understand the C source code.
Let's try to fix this. If each page of the documentation linked back to
the relevant C source code (e.g. via an online git viewer), userland
devs might actually click those links and learn how PHP works behind the
scenes. It that happens, it has great potential to both massively boost
the number of people working on the core and dramatically reduce the
amount of noise on bugs.php.net. At the very least, it would raise
awareness of how each built-in function, method, and class actually
works, which is better than people *guessing* as to how they work in
comments and forums across the Internet and on php.net itself. Nothing
is more frustrating than to see someone incorrectly guess how a software
product works when the source code to that product is readily
available.
I realize linking back to the C source code from the documentation is a
fairly involved task. A new documentation section would have to be
standardized upon, every page of the XML source would have to be updated
to add the section, and then every change verified. Keeping the links
in sync with the main source code could be a challenge as well. It
might also require tagging the core with some sort of common format,
which would, of course, cause no small upheaval on the internals list.
--
Edit bug report at https://bugs.php.net/bug.php?id=72334&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=72334&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=72334&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=72334&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=72334&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=72334&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=72334&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=72334&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=72334&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=72334&r=support
Expected behavior: https://bugs.php.net/fix.php?id=72334&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=72334&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=72334&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=72334&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=72334&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=72334&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=72334&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=72334&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=72334&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=72334&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=72334&r=mysqlcfg