1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!-- $Revision: 1.3 $ -->
<sect2 xml:id="internals2.ze1.zendapi.possibilities" xmlns="http://docbook.org/ns/docbook">
<title>Extension Possibilities</title>
<para>
As shown <link linkend="internals2.ze1.zendapi.fig.internal-struct">above</link>, PHP can be extended primarily at
three points: external modules, built-in modules, and the Zend
engine. The following sections discuss these options.
</para>
<sect3 xml:id="internals2.ze1.zendapi.possibilities.external">
<title>External Modules</title>
<para>
External modules can be loaded at script runtime using the
function <function>dl</function>. 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:
<informaltable>
<tgroup cols="2">
<colspec colnum="1" colname="col1" colwidth="*"/>
<colspec colnum="2" colname="col2" colwidth="*"/>
<tbody>
<row>
<entry colname="col1">Advantages</entry>
<entry colname="col2">Disadvantages</entry>
</row>
<row>
<entry colname="col1">
External modules don't require recompiling of PHP.
</entry>
<entry colname="col2">
The shared objects need to be loaded every time a script is
being executed (every hit), which is very slow.
</entry>
</row>
<row>
<entry colname="col1">
The size of PHP remains small by "outsourcing" certain
functionality.
</entry>
<entry colname="col2">
External additional files clutter up the disk.
</entry>
</row>
<row>
<entry colname="col1"></entry>
<entry colname="col2">
Every script that wants to use an external module's
functionality has to specifically include a call to
<function>dl</function>, or the <literal>extension</literal>
tag in <filename>php.ini</filename> needs to be modified
(which is not always a suitable solution).
</entry>
</row>
</tbody>
</tgroup>
</informaltable> 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.
</para>
<para>
Third parties might consider using the
<literal>extension</literal> tag in <filename>php.ini</filename>
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.
</para>
</sect3>
<sect3 xml:id="internals2.ze1.zendapi.possibilities.builtin">
<title>Built-in Modules</title>
<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:
<informaltable>
<tgroup cols="2">
<colspec colnum="1" colname="col1" colwidth="*"/>
<colspec colnum="2" colname="col2" colwidth="*"/>
<tbody>
<row>
<entry colname="col1">Advantages</entry>
<entry colname="col2">Disadvantages</entry>
</row>
<row>
<entry colname="col1">
No need to load the module specifically; the functionality is
instantly available.
</entry>
<entry colname="col2">
Changes to built-in modules require recompiling of PHP.
</entry>
</row>
<row>
<entry colname="col1">
No external files clutter up the disk; everything resides in
the PHP binary.
</entry>
<entry colname="col2">
The PHP binary grows and consumes more memory.
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
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.
</para>
</sect3>
<sect3 xml:id="internals2.ze1.zendapi.possibilities.engine">
<title>The Zend Engine</title>
<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.
</para>
</sect3>
</sect2>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"../../../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->
|
