CatalystやDBICのプラグイン／コンポーネントの継承の話

NEXTやClass::C3に気持ち悪い一面があるのは事実だけれど、いくらフックポイントを用意しても、空気を読まずにフックポイントの用途を意図的／非意図的に誤解して想定外のことをすれば気持ち悪いことになってしまうのは変わらない。その辺はたとえばフックポイントが豊富に用意されているPlaggerでSmartFeed系のプラグインを使ったあとにソート／フィルタ系の野良プラグインを使おうとしてハマるのといっしょ。

それでもPlaggerの場合はmiyagawaさんがOKしたもの以外はtrunkに入れず、野良の開発陣まで含めてみんな勝手にプラグインをCPANにアップしたりしないという統制がきいていたからCPAN経由での問題はあまり起こらなかったし、ときおり野良プラグインで問題が起こっても「野良だからしょうがないよね」という諦めがあったけれど、Catalystの場合はみんなが玉も石もとりあえずCPANにアップするから、CPANレベルで見るとプラグイン間の相性（や効果）に問題があるものが混じっているというだけのこと。

先日のCatalyst::Model::Jifty::DBIの件のように、開発チームがプラグインの作者に直接連絡できる場合にはそれなりのフォローが入るし、search.cpan.orgで検索をかければいくつかの（開発陣に近い人の）プラグインについてはきちんとDEPRECATEDになった旨明記されていたり、Catalyst::Plugin::Static::Simpleのように、PODの中にCompatibilityについて一筆書いてある。

ただ、Catalyst::Plugin::DateTimeのようにコアチーム（というかmst）がDISっているプラグインでも、作者が疎遠だと（わざわざ作者に連絡を取るほどの障害をもたらすわけでもなければ）そのまま放置されてしまう。

それが問題だと思うなら、IRCなりMLなりに入ればその辺の空気はある程度伝わってくるし、セッションとか認証、キャッシュまわりについてはすでにそれなりに統制をとろうという動きもあるから、不満があるなら担当している人たちに連絡をとってみるのもいいと思う。もちろん、いちいちそんなものを追いかけるくらいなら全部自前のプラグインで済ませてしまうというのもひとつのやり方だし、Catalystを捨ててJiftyを使うのもひとつのやり方。

何にしても、DISられるべき対象はCatalyst本体なんじゃなくて、NEXTなりClass::C3なりを使っているという空気を読んでないプラグインの作者だったり、その辺無頓着にプラグインを選択しているアプリケーションの開発者自身なんじゃなかろうか、と。