internals2.ze1.zendapi.html
来自「php的帮助文档,涉及到PHP的案例和基本语法,以及实际应用内容」· HTML 代码 · 共 1,583 行 · 第 1/5 页
HTML
1,583 行
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html> <head> <title>Zend API: Hacking the Core of PHP</title> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body><div style="text-align: center;"> <div class="prev" style="text-align: left; float: left;"><a href="internals2.ze1.streams.html">Streams API for PHP Extension Authors</a></div> <div class="next" style="text-align: right; float: right;"><a href="internals2.ze1.tsrm.html">TSRM API</a></div> <div class="up"><a href="internals2.ze1.html">Zend Engine 1</a></div> <div class="home"><a href="index.html">PHP Manual</a></div></div><hr /><div id="internals2.ze1.zendapi" class="sect1"> <h2 class="title">Zend API: Hacking the Core of PHP</h2> <div id="internals2.ze1.zendapi.intro" class="sect2"> <h3 class="title">Introduction</h3> <p class="para">Those who know don't talk.</p> <p class="para">Those who talk don't know.</p> <p class="para"/> <p class="para"> Sometimes, PHP "as is" simply isn't enough. Although these cases are rare for the average user, professional applications will soon lead PHP to the edge of its capabilities, in terms of either speed or functionality. New functionality cannot always be implemented natively due to language restrictions and inconveniences that arise when having to carry around a huge library of default code appended to every single script, so another method needs to be found for overcoming these eventual lacks in PHP. </p> <p class="para"> As soon as this point is reached, it's time to touch the heart of PHP and take a look at its core, the C code that makes PHP go. </p> <div class="warning"><b class="warning">Warning</b> <p class="para"> This information is currently rather outdated, parts of it only cover early stages of the ZendEngine 1.0 API as it was used in early versions of PHP 4. </p> <p class="para"> More recent information may be found in the various README files that come with the PHP source and the <a href="http://devzone.zend.com/public/view/tag/Extension" class="link external">» Internals</a> section on the Zend website. </p> </div></div> <div id="internals2.ze1.zendapi.overview" class="sect2"> <h3 class="title">Overview</h3> <p class="para"> "Extending PHP" is easier said than done. PHP has evolved to a full-fledged tool consisting of a few megabytes of source code, and to hack a system like this quite a few things have to be learned and considered. When structuring this chapter, we finally decided on the "learn by doing" approach. This is not the most scientific and professional approach, but the method that's the most fun and gives the best end results. In the following sections, you'll learn quickly how to get the most basic extensions to work almost instantly. After that, you'll learn about Zend's advanced API functionality. The alternative would have been to try to impart the functionality, design, tips, tricks, etc. as a whole, all at once, thus giving a complete look at the big picture before doing anything practical. Although this is the "better" method, as no dirty hacks have to be made, it can be very frustrating as well as energy- and time-consuming, which is why we've decided on the direct approach. </p> <p class="para"> Note that even though this chapter tries to impart as much knowledge as possible about the inner workings of PHP, it's impossible to really give a complete guide to extending PHP that works 100% of the time in all cases. PHP is such a huge and complex package that its inner workings can only be understood if you make yourself familiar with it by practicing, so we encourage you to work with the source. </p> <div id="internals2.ze1.zendapi.overview.whatisit" class="sect3"> <h4 class="title">What Is Zend? and What Is PHP?</h4> <p class="para"> The name <em class="emphasis">Zend</em> refers to the language engine, PHP's core. The term <em class="emphasis">PHP</em> refers to the complete system as it appears from the outside. This might sound a bit confusing at first, but it's not that complicated ( <a href="internals2.ze1.zendapi.html#internals2.ze1.zendapi.fig.internal-struct" class="link">see below</a>). To implement a Web script interpreter, you need three parts: <ol class="orderedlist"> <li class="listitem"> <p class="para"> The <em class="emphasis">interpreter</em> part analyzes the input code, translates it, and executes it. </p> </li> <li class="listitem"> <p class="para"> The <em class="emphasis">functionality</em> part implements the functionality of the language (its functions, etc.). </p> </li> <li class="listitem"> <p class="para"> The <em class="emphasis">interface</em> part talks to the Web server, etc. </p> </li> </ol> Zend takes part 1 completely and a bit of part 2; PHP takes parts 2 and 3. Together they form the complete PHP package. Zend itself really forms only the language core, implementing PHP at its very basics with some predefined functions. PHP contains all the modules that actually create the language's outstanding capabilities. <div class="mediaobject"> <div class="imageobject"> <img src="figures/zendapi.ze1.01-internal-structure.png" alt="The internal structure of PHP." /> </div> </div> </p> <p class="para"> The following sections discuss where PHP can be extended and how it's done. </p> </div> </div> <div id="internals2.ze1.zendapi.possibilities" class="sect2"> <h3 class="title">Extension Possibilities</h3> <p class="para"> As shown <a href="internals2.ze1.zendapi.html#internals2.ze1.zendapi.fig.internal-struct" class="link">above</a>, PHP can be extended primarily at three points: external modules, built-in modules, and the Zend engine. The following sections discuss these options. </p> <div id="internals2.ze1.zendapi.possibilities.external" class="sect3"> <h4 class="title">External Modules</h4> <p class="para"> External modules can be loaded at script runtime using the function <a href="function.dl.html" class="function">dl()</a>. This function loads a shared object from disk and makes its functionality available to the script to which it's being bound. After the script is terminated, the external module is discarded from memory. This method has both advantages and disadvantages, as described in the following table: <table class="informaltable"> <colgroup> <col align="left" width="0" /> <col align="left" width="0" /> <tbody valign="middle" class="tbody"> <tr valign="middle"> <td colspan="1" rowspan="1" align="left">Advantages</td> <td colspan="1" rowspan="1" align="left">Disadvantages</td> </tr> <tr valign="middle"> <td colspan="1" rowspan="1" align="left"> External modules don't require recompiling of PHP. </td> <td colspan="1" rowspan="1" align="left"> The shared objects need to be loaded every time a script is being executed (every hit), which is very slow. </td> </tr> <tr valign="middle"> <td colspan="1" rowspan="1" align="left"> The size of PHP remains small by "outsourcing" certain functionality. </td> <td colspan="1" rowspan="1" align="left"> External additional files clutter up the disk. </td> </tr> <tr valign="middle"> <td class="empty"> </td> <td class="empty"> </td><td colspan="1" rowspan="1" align="left"> Every script that wants to use an external module's functionality has to specifically include a call to <a href="function.dl.html" class="function">dl()</a>, or the <i>extension</i> tag in <var class="filename">php.ini</var> needs to be modified (which is not always a suitable solution). </td> </tr> </tbody> </colgroup> </table> To sum up, external modules are great for third-party products, small additions to PHP that are rarely used, or just for testing purposes. To develop additional functionality quickly, external modules provide the best results. For frequent usage, larger implementations, and complex code, the disadvantages outweigh the advantages. </p> <p class="para"> Third parties might consider using the <i>extension</i> tag in <var class="filename">php.ini</var> to create additional external modules to PHP. These external modules are completely detached from the main package, which is a very handy feature in commercial environments. Commercial distributors can simply ship disks or archives containing only their additional modules, without the need to create fixed and solid PHP binaries that don't allow other modules to be bound to them. </p> </div> <div id="internals2.ze1.zendapi.possibilities.builtin" class="sect3"> <h4 class="title">Built-in Modules</h4> <p class="para"> Built-in modules are compiled directly into PHP and carried around with every PHP process; their functionality is instantly available to every script that's being run. Like external modules, built-in modules have advantages and disadvantages, as described in the following table: <table class="informaltable"> <colgroup> <col align="left" width="0" /> <col align="left" width="0" /> <tbody valign="middle" class="tbody"> <tr valign="middle"> <td colspan="1" rowspan="1" align="left">Advantages</td> <td colspan="1" rowspan="1" align="left">Disadvantages</td> </tr> <tr valign="middle"> <td colspan="1" rowspan="1" align="left"> No need to load the module specifically; the functionality is instantly available. </td> <td colspan="1" rowspan="1" align="left"> Changes to built-in modules require recompiling of PHP. </td> </tr> <tr valign="middle"> <td colspan="1" rowspan="1" align="left"> No external files clutter up the disk; everything resides in the PHP binary. </td> <td colspan="1" rowspan="1" align="left"> The PHP binary grows and consumes more memory. </td> </tr> </tbody> </colgroup> </table> Built-in modules are best when you have a solid library of functions that remains relatively unchanged, requires better than poor-to-average performance, or is used frequently by many scripts on your site. The need to recompile PHP is quickly compensated by the benefit in speed and ease of use. However, built-in modules are not ideal when rapid development of small additions is required. </p> </div> <div id="internals2.ze1.zendapi.possibilities.engine" class="sect3"> <h4 class="title">The Zend Engine</h4> <p class="para"> Of course, extensions can also be implemented directly in the Zend engine. This strategy is good if you need a change in the language behavior or require special functions to be built directly into the language core. In general, however, modifications to the Zend engine should be avoided. Changes here result in incompatibilities with the rest of the world, and hardly anyone will ever adapt to specially patched Zend engines. Modifications can't be detached from the main PHP sources and are overridden with the next update using the "official" source repositories. Therefore, this method is generally considered bad practice and, due to its rarity, is not covered in this book. </p> </div> </div> <div id="internals2.ze1.zendapi.layout" class="sect2"> <h3 class="title">Source Layout</h3> <blockquote><p><b class="note">Note</b>: Prior to working through the rest of this chapter, you should retrieve clean, unmodified source trees of your favorite Web server. We're working with Apache (available at <a href="http://www.apache.org/" class="link external">» http://www.apache.org/</a>) and, of course, with PHP (available at <a href="http://www.php.net/" class="link external">» http://www.php.net/</a> - does it need to be said?). <br /> Make sure that you can compile a working PHP environment by yourself! We won't go into this issue here, however, as you should already have this most basic ability when studying this chapter. <br /> </p></blockquote> <p class="para"> Before we start discussing code issues, you should familiarize yourself with the source tree to be able to quickly navigate through PHP's files. This is a must-have ability to implement and⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?