Extending and Embedding PHP 128
Sebastian Bergmann writes "PHP is a widely-used general-purpose scripting language that is especially suited for Web development. The interpreter that executes programs written in the PHP programming
language has been designed from the ground up to be easily embeddable (for instance into the
Apache Web Server) and extendable. This extensibility is one
of the reasons why PHP became the favourite "glue" of the Web: functionality from existing third-party
libraries (database clients or image manipulation toolkits, for instance) can be made available through
PHP with the ease of use you expect from a scripting language." Read the rest of Sebastian's review.
| Extending and Embedding PHP | |
| author | Sara Golemon |
| pages | 448 |
| publisher | SAMS |
| rating | 9 |
| reviewer | Sebastian Bergmann |
| ISBN | 067232704X |
| summary | The new standard work on extending and embedding PHP. |
"Extending and Embedding PHP" by Sara Golemon, a long-time contributor to the PHP project, remedies the fact that the internals of PHP are far from being as well documented as the rest of PHP. It brings writing extensions for PHP "to the masses", so to speak.
After a short introduction that makes the reader familiar with terms like PHP Extension, Zend Extension, Userland, and Internals that are used throughout the book, Chapter 1 ("The PHP Life Cycle") opens with an overview of how the PHP Interpreter works and what parts (TSRM, Zend Engine, SAPI, "PHP") it comprises.
Chapter 2 ("Variables from the Inside Out") shows how PHP handles and stores variables internally. The reader learns how to distinguish types, set and retrieve values, as well as how to work with symbol tables. It is in this chapter that the fundamental unit of data storage in PHP, the so-called zval (short for Zend Value) is discussed.
Chapter 3 ("Memory Management") builds upon the previous chapter and discusses more advanced operations on zvals, for instance creating and dealing with copies of a zval or the destruction of a zval when it is no longer needed. To this extent, the Zend Memory Manager is discussed as well as underlying principles such as Reference Counting and Copy-on-Write, for instance.
Chapter 4 ("Setting Up a Build Environment") guides the reader through setting up an environment, either on *NIX or on Microsoft Windows, for the development and debugging of PHP and PHP extensions.
After these first four chapters, the reader is ready to go about writing his or her first PHP extension. Chapter 5 ("Your First Extension") takes the reader through the steps necessary to write and build a simple working PHP extension. The following chapters build upon the knowledge gained here, so that the reader can ultimately implement or change any type of PHP feature.
Chapter 6 ("Returning Values") explains how to pass values (by value, by reference, and through their parameter stack using references) from internal (C-level) functions or methods to userland (PHP-level).
Chapter 7 ("Accepting Parameters") deals with the mechanisms involved in accepting parameters from userland calls to an internal function or method. This includes the discussion of the zend_parse_parameters() API which makes the parameters that are passed to the internal function or method as indirect zval references usable in your C-code. The handling of optional and arbitrary numbers of parameters is explained as well as the usage of type hinting and its arg_info API.
Chapter 8 ("Working with Arrays and Hash Tables") explains the Zend Engine's HashTable API, which is used to store any piece of data of any size, in detail. Its different data storage mechanisms supported are introduced and compared. To quote from the book, "A HashTable is a specialized form of a doubly linked list that adds the speed and efficiency of vectors in the form of lookup indices". Since these structures are used heavily throughout the Zend Engine and PHP and its extensions, a good understanding of this API is vital for any aspiring PHP extension developer.
Chapter 9 ("The Resource Data Type") introduces the reader to the first complex data type (excluding the Array data type that was discussed in the previous chapter, which is just a collection containing primitive data types like strings or numbers). A resource can be, for instance, a connection to a database. It allows the PHP extension developer to "connect abstract concepts like opaque pointers from third-party libraries to the easy-to-use userspace scripting language that makes PHP so powerful".
Chapters 10 ("PHP 4 Objects") and Chapter 11 ("PHP 5 Objects") delve into the last data type supported by the Zend Engine: objects. Sara Golemon dedicates one chapter each to the respective APIs of PHP 4 and PHP 5 because of the huge advancements that were introduced in PHP 5 and that totally changed the APIs.
After the previous chapter, all data types supported by the Zend Engine have been discussed and the book revisits a topic discussed earlier in the book: that of the PHP Interpreter's life cycle. Chapter 12 ("Startup, Shutdown, and a Few Places in Between") explains how to add state to a PHP extension by using thread-safe globals. Along the way, concepts such as internal and external (super) globals as well as thread safety are discussed.
Chapter 13 ("INI Settings") shows how a PHP extension can be made ready for runtime configuration through php.ini settings.
The next three chapters ("Accessing Streams", "Implementing Streams", and "Diverting the Stream") make the reader familiar with yet another important API of PHP: the Streams API. All file input/output in PHP userspace is processed through PHP's Streams Layer. This layer, that was introduced in PHP 4.3, is what makes working with files, compressed files, and remote files, for instance, seamlessly in PHP. The reader learns how to work with streams as well as how to expose streamable resources, whether remote network input/output or local data sources, using the Streams API, thus avoiding the need to reimplement all the tedious bits and pieces that are normally associated with this.
Chapter 17 ("Configuration and Linking") builds upon the tools and techniques introduced in Chapter 4 and adds the GNU autotools (autoconf, automake, and friends) to the reader's set of tools. These tools, if used correctly, allow the extension to be built in environments that the extension author does not know or has no access to.
Chapter 18 ("Extension Generators") takes a look at ext_skel (which comes with the source distribution of PHP) and PECL_Gen (which can be obtained, as the name suggests, from PECL, the PHP Extension Community Library). These two tools automate most of the steps described in the previous chapter and take a lot of tedious work out of the extension writer's hands.
Starting with simple embedding examples, the reader learns in Chapter 19 ("Setting Up a Host Environment") and Chapter 20 ("Advanced Embedding") how the PHP Interpreter can be embedded into almost any other application.
The book concludes with the "Zend API Reference", "PHP API Reference", "Extending and Embedding Cookbook", and "Additional Resources" appendixes. The first two are a great resource for both novice and experienced PHP extension writers (even for people working on PHP and the Zend Engine itself). The third features a collection of common use code snippets while the last one points the reader into the direction of PECL by suggesting a couple of existing extensions to look at and learn from.
Since the topic of this book is to extend the PHP Interpreter using extensions written in the C programming language (or to embed it into an application that is written in C), a good understanding of C syntax, its datatypes, and pointer management is important to get the most out of this book.
Being a contributor to the PHP project for about six years now, I have been looking forward to this book. True, there is always the source code of the PHP Interpreter as a source of information on how "things work". But although being the ultimate reference, reading the source code cannot replace a thoughtfully structured and well written guide that gets you started. If you are looking for such a guide, look no further: you will find it in this excellent book.
Although it deals with a very technical topic, "Extending and Embedding PHP" is readable and the many code examples are easy to follow. The reader profits from the knowledge of the author, who has been involved in the PHP project as a core developer for over four years now and is also the author and maintainer of a dozen PHP extensions that are available through PECL. The book covers both major versions of PHP that are currently used, PHP 4 and PHP 5, and it will continue to serve its purpose when PHP 6 comes out next year.
Sebastian Bergmann spends his free time with the development of Free Software, is a member of the PHP and Gentoo Linux development teams and author of a variety of PHP software projects such as PHPUnit."
You can purchase Extending and Embedding PHP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Other People's Code (Score:3, Insightful)
Agreed, especially when the source code you're reading isn't your own. I claim that 99% of programmers who are not me write totally obfuscated code. Damn them!
Re:I'd rather see a review (Score:1, Insightful)
Re:5 of first 7 comments trolling (Score:4, Insightful)
I think PHP has replaced Java as the favorite "kick the dog" language on Slashdot. IMHO, PHP is no different than any other language. It takes work to write consistently clear code that other people can understand.
Re:5 of first 7 comments trolling (Score:3, Insightful)
Re:5 of first 7 comments trolling (Score:2, Insightful)
Re:5 of first 7 comments trolling (Score:1, Insightful)
It's pretty bad. To begin with there's therandom() naming_scheme(). On top of that there's the lack of namespace support, so we have str_pad and strlen rather than something like:
The devs should add namespaces and camelCase all function names (Currently function names are case insensitive). They could even have a secondary function table with aliases for backwards compatability, since simple sed commands or search and replace are apparently too esoteric for the PHP userbase :-o
You know, there's simply too much wrong to list it all. Most of the gripes are against PHP4 which I haven't used in 2 years, hopefully PHP5.2 should sound the death toll for PHP4. Overall I'd like to ditch PHP and use a cleaner dynamic language with compilation targeting a JIT'd VM (No, not one designed for languages with static type systems).
Ruby zealots are envious (Score:2, Insightful)
That's because there are people who are trying to reinvent a 40+ years old language who do not like the way PHP has taken over the web. They simply hate the way sites with page names ending in ".php" outnumber sites with pages names ending in ".rb".
Those people are too stupid to understand Lisp, too ignorant to know the good points of Lisp, and too close-minded to try learning how to use Lisp, therefore they tried to create a hybrid language by attaching some of the Fortran syntax to Lisp, creating Ruby in the process.
Re:Why I don't like PHP (Score:2, Insightful)
Yes there is: error_reporting(E_STRICT);
Bash PHP For Fun and Profit (Score:4, Insightful)
To the PHP bashers - you might succeed in selling something new but after the next guy inherits your spaghetti code they will start bashing *you*.
Don't be fooled people. Every language has it's corners. I spend 90% of my time doing C but I just spent a month doing a standard LAMP site and I just don't see what these guys are hee'n and haw'n about. PHP is just as useful today as it was on 1998 so I'm willing to bet it will be around for a long time still. Don't be influenced by some bored guy saying "it sucks" and "I hate it". That's just not intelligent criticism. Try different things and make up your own mind.
PHP has a huge install base and has served us very well for many years. Let's not forget that. The PHP bashers pushing Python and Ruby should be ashamed of themselves. Post some useful information about how Python or Ruby solves a problem you think PHP has. And no cryptic one liners thank you. Get a spine and post some useful comments.
Re:PHP is not just for the web (Score:3, Insightful)
If you're looking for the lastest hot new "technology" then Ruby is a good buzzword. Otherwise, if you're just looking to get work done, so you can go home and play with your kids, PHP is a workhorse.
No, it isn't.
Sorry, but this post sounds very blinkered. You are ignoring the 'elephant in the room'. The dominant thing that many people pretends does not exist.
The workhorse is now Java. It has unmatched support for databases, unparalleled library support. There are so many tools and frameworks for Java that anyone can find something suitable. There are rich and powerful open source and commercial IDEs. Java is now the major language for 'heavy lifting'.
Ruby is not the hot new technology. It is simply the hot new topic of conversation. There is a big difference. Ruby has neither the performance or the capabilities (such as internationalisation) for major use. It has virtually no significant presence in commercial development and has hardly impacted the dominance of PHP for open source web development.
It is sad to see how many people comment on major international forums who aren't prepared to look beyond their own personal experience, and get a real feel for what is actually happening in the industry.
Re:5 of first 7 comments trolling (Score:4, Insightful)
I couldn't have said it better myself. I personally use PHP for many small applications. I also make sure to heavily comment my code, and I try not to obfuscate my code (it kills me that some people compete to see who can write the most obfuscated Perl, for example. Try interpreting or revising that code a year from now).
Many times I've had to revisit code years after having written it, and when there are no comments, it is difficult to see what exactly I was thinking at the time -- in *any* language. Non-descriptive variable names, or attempting to put as much code in as few lines possible, are, IMHO, bad practices.
Personally I see nothing inherently wrong with PHP. If I'm working with a web-based application, under Apache, using a MySQL database, PHP is the first thing that comes to mind. Image manipulation (now integrated) and HTTP features (headers, cookies, form data, file uploads, etc) make PHP an easy choice for many web applications. I've done all of this in Perl, and some in plain-old-C, but PHP makes these things so easy...
Of course it's not for everything. I try to use whatever platform/language is most appropriate for the application at hand. Sometimes it's C or C++, perhaps it's Perl, whatever - I use whatever makes the most sense for what I'm hoping to accomplish. It just happens that, on my Linux server, PHP often stands out as the best choice. When writing Windows applications, I use a hybrid of VB6 and (in the form of a back-end DLL library) C/C++. On the server, PHP most often comes out as the clear choice. Ease of use, abundance of built-in functions/features, ease of database-to-web integration, and relative security all make PHP a good choice for many of my projects and ideas.
Some have referred to PHP as "loose", and I admit sometimes it can be. There is no equivalent to Perl's "use strict", and it's easy to unintentionally leave an opportunity for a user to pass unexpected variables -- but as long as you are able to keep this in mind, it's not difficult to make a relatively secure PHP script. Just make sure any important variables are declared/set/validated at the start of the script. I admit, I do love Perl's "strict" module, since it leaves no question as to whether a variable's data is trustworthy... but PHP is a different language, with different features. You can't discount it as a viable language because of a single missing feature...
Re:5 of first 7 comments trolling (Score:3, Insightful)