PEAR 1.x は、PEAR インストーラ対応のコードを管理するという点で大きな成功を収めました。 新たなインストーラである Pyrus は、これをさらに拡張して PEAR アプリケーション以外も扱えるように設計されており、 単純に zip を展開してインストールするのと同様に動作します。 PEAR2 リポジトリは、PEAR リポジトリよりも幅広いコーディング規約に対応できるようになっています。 このドキュメントでは、here にある既存のルールやコーディング規約からの変更点をすべてとりあげます。 ここにあげた規約とこれまでの規約が矛盾する場合は、新しい標準規約のほうを優先します。 また、この規約は pear.php.net で管理している PEAR パッケージには何の影響も及ぼしません。 あくまでも pear2.php.net で管理することになる PEAR2 パッケージに対してのみ有効となります。

require_once を使用するとパッケージの構造についての制約が多くなり、 PEAR パッケージの可能性を制限してしまいます。たとえば以下のような問題があります。

• require_once を使用すると、マルチプロセッサのウェブサーバを使用した大規模サイトでは 10% 程度のパフォーマンスの低下が見られます。 これは、待ち時間が増加することによるものです。 しかし、シングルプロセッサのシステムを使用しているであろう大半のユーザにとっては、 パフォーマンスの低下は最大でも 2% となります (Yahoo! のエンジニア Gopal Vijayaraghavan の計測より)。
• そのパッケージを使用するために、include_path の設定が必要となります。 そのせいで、独自の include_path を持つ別のアプリケーションに PEAR をバンドルすることが難しくなります。 また、必要なクラス群をすべてひとつのファイルにまとめることも難しくなりますし、 PEAR パッケージを phar アーカイブにまとめる際にもソースコードの修正が必要となります。
• トップレベルの require_once と条件付きの require_once を混用すると、 APC (PHP 6 にバンドルされる予定) のような opcode キャッシュ機能がうまく働かなくなります。
• require_once を相対パスで指定するには、 include_path が適切に設定されている必要があります。つまり、 include_path が適切に設定されていなければそのパッケージが使えなくなるわけです。

require_once には、利点もあります。

• 必要なファイルが存在しなければ Fatal Error: missing file X となるので、すぐに気づくことができます (PEAR2_Autoload() で __autoload() を使用することで対応できます)。
• エンドユーザは、そのパッケージ内でどんなファイルを使用しているのかを気にせずにすみます (これもまた PEAR2_Autoload() で __autoload() を使用することで対応できます)。

require_once をなくしてしまうと、その代わりに依存ファイル (パッケージ内のファイルあるいは外部のファイル) を読み込む仕組みが必要になります。 ここでは、ふたつの方法を紹介します。

• PEAR2 の自動ロード機能 (svn の ここ にあります) と __autoload() を組み合わせて使用する

• 必要なファイル群を読み込むための独自の仕組みを作成する

いずれにせよ、必要なファイル群を読み込むのはエンドユーザ側の仕事となります。 しかし、初心者向けには、PEAR2/Autoload.php を読み込みさえすればすべてうまくいくようになっています。 このファイルは新規パッケージには常にバンドルされていますが、 zip を展開してそのまま使用する形式の場合にのみ展開されます (pyrus は、点順に PEAR2 上の依存ファイルをインストールします。 この中には、必要となるベースファイル PEAR2_Exception および PEAR2_Autoload が含まれます)。

PEAR2/Autoload.php は、include_path が正しい値に設定されていない場合に自動的に設定し、 ユーザが定義していなければ自動的に __autoload() を宣言します。