PEAR
What is PEAR ?
公式サイトのトップページに、PEARとはなにかがこのように説明されています。
What is PEAR ?
PEAR is a framework and distribution system for reusable PHP components.
PEARはフレームワークであり、再利用可能なPHPコンポーネントのディストリビューションシステムです。
PEARの持つ2つの側面。フレームワーク、ディストリビューションシステムと簡潔に説明されています。
PEARの誤解
PEARは一般にいくつか誤解されてるようです。
グローバル
PEARはグローバル専用でなく、「ひとつのプロジェクトにおける依存関係を管理」に利用することは可能です。特殊なHackなどではなく、標準で用意された方法です。
.pearrcをconfig-createで作って、オプションで指定するだけです。
BEAR.Saturdayでもユーザー環境へのインストールを紹介していて、実際多くのプロジェクトがプロジェクト単位で構築されて駆動しています。
チャンネル
作成したパッケージをwebでサービスするために、パッケージ登録のための投票を受ける必要はありません。それは公式のチャネル pear.php.netでの話です。公式に載せていない、独自のチェンネルでサービスをしているパッケージも沢山あります。BEAR.Satuday http://pear.bear-project.net/ もその一つです。
どちらも改善の余地はあるものだったのでしょうが、機能的には可能でした。またPEARの大きな特徴として後方互換性の完全な維持がありました。
BCブレイク
PEARは後方互換性を破らないという厳しいルールがありました。BEAR.Saturdayは沢山の依存PEARパッケージがあり、数えきれないほどPEAR upgradeしましたが問題が出た記憶がほとんどありません。 バージョンが.1あがったら互換性でエラーだらけになるような事は決してありませんでした。
依存管理で正確なバージョンを特定しなくても、最新バージョンを入れれば機能しました。しかしこれは、そこまで厳格でないパッケージの依存を扱う時に困った事になります。composer.lockのような機構はありませんでした。PEARのような高い品質を持ったライブラリ同士でなければ問題になってしまいます。
PEARはフレームワーク
PEARはコード作成に関する標準スタイルや共通のエラーメカニズム、バージョニング、ディストリビューションをも含んだ包括的なフレームワークです。Internet ArchiveによるとPEARに初出は2001年です。こんなに速い時期からこんなフレームワークが提供できたのはPHPコミュニティの誇れる歴史です。
後に続く非PEARのアプリケーションフレームワークやライブラリは、この偉大な先輩にリスペクトを持ったものと、全く持たないものがありました。コーディング規約やフォルダ構造を見れば分かります。1 例えばPEARのフォルダ構造はPseudo-namespace(PHP5.3以前のなんちゃって名前空間)に従ったもので一貫性がありauto loaderが簡単に実装できましたが、独自のフォルダ構造をもちクラスファイルの読み込みに大変なコストがかかるものもありました。2
ただ、その高すぎる理想と、GitHubを中心とした新しいコーディング文化、PHP5.3以降のライブラリ群の依存要求、Pyrus移行の失敗、など様々な要因によってPHPの依存管理の主役の座をComposerに明け渡す事になります。
しかしPEARは当時のPHPの最良を提供しようとした、意欲的で完成度の高い包括的なエコシステムです。今のPSRやコーディングにも多くの影響を与えています。単に古く間違ったプラクティスとして忘れてしまおうという考えには賛同できません。主役の座は受け渡しましたが、今でもいくつものライブラリは有用だしディストリビューションシステムとしても健全で機能します。公式サイトでホストされてるライブラリは複数のレビュアーが承認した質の高いコードで、コードリーディングのテキストとしても有用です。
PEARはPHPコミュニティの誇れるべき財産だと考えます。