How do I start reading the PHP source code?

Question

The source code for the PHP interpreter is absolutely mystifying to me. The thing is, I'd like to learn more about it, so I can avoid making Schlemiel-style mistakes.

This is a huge project, some nearly sixty megs in size. How do I go about reading it? Is there an article or a book out there somewhere to help me begin to make some sense of it?

(Note: Markdown eats my link to wikipedia's entry on Schlemiel the painter. It's: http://en.wikipedia.org/wiki/Schlemiel-the-painter's-Algorithm, replacing hyphens for underscores.)

Answer 1

If your interested in just how various functions work you can find them here.

php-5.2.6\ext\ - all the extensions like mysql, pdo, soap, etc ...
php-5.2.6\ext\standard - standard php functions like sort, count, etc...

I would start by looking at some simple functions and figuring out how they work. Create a project in an IDE that supports function look-up. This way you can just click on a function and jump to it's definition. Makes it a lot easier to follow code as you learn what does what.

I found this cool tool under PHP: A Tourist's Guide on php.net
PHP Cross Reference - "This is the ultimate tool for exploring PHP code."

There are some good readme files that come with the source code. I recommend reading these before you dive in the source code since they talk about how the source code functions.

README.PARAMETER_PARSING_API
README.STREAMS

Answer 2

Personally I would recommend learning PHP yourself. You can pick up a decent O'Reilly book for not much cash if you're willing to shell out at all.

Alternatively there are resources on the web, but I tend to find these slightly less useful/accurate/explanatory, so I'll let you search for those yourself. A good place to start, besides google, is php.net.

If you're already a programmer, however, you should be able to follow it fairly simply. Chances are the source code is object-oriented if it's that big, and most people tend to split their objects up into either one object per file, or a few related objects per file.

Start with the index.php file and start tracking the code. Follow include files, and try to understand sections of it at a time. If it is well-written, many functions should be named and written such that you don't need to know how it works, and you can safely skim over the gory details, content to know that it works and not how.

Also I recommend dead tree notebooks to scrawl on. These are invaluable to help you remember where you were in code when you start following code paths through several files.

And ultimately, you could probably contact the author, or ask in IRC or on newsgroups and mailing lists, for help in what certain things do. Don't forget the documentation! If there is any (and if there isn't, it's a hangable offence), it'll certainly help you decide which bits you need to know about now, and which you can find out about later.

Answer 3

It all depends on your final goal. Do you:

1. just want to understand how the whole thing works on some high level, or
2. want to find and change something in particular, or
3. want to know how everything works in detail?

I did 2. some time ago, and it was rather easy. I used doxygen to index the entire codebase to HTML, so I can browse it easily in a web browser. IMHO, using a tool like that is a must. For example, anywhere you see some function, macros or variable, you can click on it to see where it is defined, and list of all other places in code where it is used.

As for PHP code, I liked the way it is structured. It isn't over complicated, and it isn't too hard to understand. Of course, it is possible that for some details you might need to ask at PHP development list, but I didn't find such case in my little task.

Based on my experience, I can offer you few starting points. The whole thing in managed by code in Zend/zend.c file. The loading of source is done in Zend/zend_stream.c via main/fopen_wrappers.c and main/stream/plain_wrapper.c, after which is goes in Zend/zend_language_scanner.c and Zend/zend_language/parser.c.

Well, you wanted a starting point, I guess this should be enough?