PHP マニュアル
前のページ | 第 46章Zend API: PHP のコアをハックする | 次のページ

# 拡張の可能性

先に示した 図46-1 のとおり、 PHP を拡張するには 3 つの方法があります。それは 外部モジュール・組み込みモジュール・Zend エンジン の 3 つです。以下の節で、これらそれぞれについて考えます。

## 外部モジュール

外部モジュールは、スクリプトの実行時に dl() 関数を使用して読み込みます。この関数は、ディスクから共有オブジェクトを 読み込んで、呼び出し元のスクリプトからその機能を使用できるように します。スクリプトが終了すると、外部モジュールはメモリから削除 されます。この方法には利点も欠点もあります。それを以下の表にまとめます。

利点 | 欠点
PHP をコンパイルせずに外部モジュールを使用できる。 | スクリプトが実行されるたび (アクセスされるたび) に 共有オブジェクトを読み込む必要があり、速度が非常に遅くなる。
その機能を「外部にまかせる」ことにより、PHP のサイズを 小さく抑えられる。 | 外部の追加ファイルによってディスクを散らかしてしまう。
| そのモジュールの機能を使用するすべてのスクリプトが dl() をコールするか、あるいは `php.ini` の中の extension タグを変更する (この方法が適切でない場合もある) 必要がある。

要するに、外部モジュールが有用なのは以下のような場合です。 サードパーティの製品・PHP のちょっとした機能拡張で、めったに 使われないもの・単なるテスト目的で作成するものなど。 追加機能を手っ取り早く開発するには、外部モジュールが最適です。 頻繁に使用するものであったり大規模な実装であったり、あるいは 複雑なコードの場合などは、欠点が利点を上回ってしまうでしょう。

サードパーティは、`php.ini` の extension タグを使用して PHP に拡張モジュールを 追加することを考えるかもしれません。これらの拡張モジュールは 本体のパッケージとは完全に切り離されます (これは、商用の環境では とても便利な機能です)。商用製品を配布する場合は、単に追加モジュール のみを含むディスクやアーカイブを出荷すればよいのであり、他の 拡張モジュールが使用できなくなるような PHP バイナリを作成する 必要がなくなります。

## 組み込みモジュール

組み込みモジュールは、PHP のコンパイル時に直接組み込まれ、PHP プロセスと一緒に動作します。すべてのスクリプトで、その機能が 使用可能となります。外部モジュールの場合と同様、組み込みモジュールに ついても利点と欠点があります。それを以下の表にまとめます。

利点 | 欠点
いちいちモジュールを読み込む必要がない。 なにもしなくてのその機能が使用できる。 | 組み込みモジュールを更新するには PHP を再コンパイル する必要がある。
別の外部ファイルでディスクを散らかすことはない。 すべては PHP のバイナリに組み込まれる。 | PHP バイナリのサイズが大きくなり、メモリ消費量も増える。

比較的変更の少ない安定した関数のライブラリで、平均以上の速度を 要求するものであったり、あるいは多くのスクリプトから頻繁に 使用されるようなライブラリなどの場合は、組み込みモジュールに するのが最適です。PHP を再コンパイルしなければならないという 問題は、それによって得られるスピードや使いやすさにくらべたら たいしたことはありません。しかし、小さな変更が頻繁に繰り返される ような場合には、組み込みモジュールは不適当です。

## Zend エンジン

もちろん、拡張機能を Zend エンジンに直接組み込むこともできます。 言語そのものの振る舞いを変更したい場合、あるいは言語のコアに 特別な関数を直接組み込む必要がある場合などには、この方式がよいでしょう。 しかし、一般的には Zend エンジンを変更することは避けるべきです。 ここを変更してしまうとその他の部分で非互換性が発生する可能性があり、 特別に変更された Zend エンジンに対応できる人は誰もいなくなるでしょう。 変更内容を PHP のソースから切り離すことができなくなりますし、 また「公式」なソースリポジトリからアップデートを行うと、変更内容が 上書きされてしまいます。そのため、この手法はよくないものと 考えられています。使用することはめったにないため、この文書では この手法については取り上げません。

前のページ | ホーム | 次のページ
概要 | 上に戻る | ソース配置