Mooseを使うか使わないか
2009年9月1日 Dave Cross

私は結構な期間Mooseについて知識がある。私が始めてトレーニングコースでMooseについて言及したのは、2007年夏に遡って、Teach-Inにおいてだった。それ以来、Mooseはトレーニングコースの一部となっている。

しかし、トレーニングコースで人にMooseについて話していても、私は実際に自身のコードの中には使っていなかった。フリーランサーとして明らかに、日常の仕事において、私の顧客が使っているテクノロジーが何であれ、それを使うことに余儀なくされる。私はまだ、Mooseを既に使っているプロジェクトの仕事を受けていない（私は数人の顧客にMooseに切替えてはいかがと勧めているけれども）。

私自身のコードは別だ。そのコードは主に私のCPANモジュールである。最近まで、それらのどれにもMooseを使わなかった。Mooseを使った私の最初のリリースは、Guardian::OpenPlatform::APIだった。始めからMooseを直ちに使った新しいモジュールだ。しかし、結局のところ、Mooseが適切である場所ならどこでもMooseを使うように、遡って既存のモジュールをリファクタリングしたくなる、ことが分かった。

今年のYAPC::Europeへ行き、Mooseがいかに素晴らしいかを面と向かって私に語る人々の一週間に付き合わされた。そして、歯を食いしばってリファクタリングを始める時だと決心した。

私が試みた次のモジュールがParse::RPM::Specだった。2つの理由のため、これを選んだ。第一に、それが正にアトリビュート主導型のモジュールであるから。スペックファイルの初期読込みを別にして、このクラスのオブジェクトはただアトリビュートの値を返すために存在する。これは非常にMooseと相性がよい。事実、Mooseを使うようにコンバートすることは、コード削減の主なケースだった。第二に、もっと実際的なことだった。つまり、私が知っている限り、このモジュールを使っている人はいないので、私が何かを壊しても、私を罵る群衆がいないであろう。

そのコンバージョンのいとも簡単さに感心したので、私はArray::Compareに移った。このモジュールは、私の最初のCPANモジュールだったので、特別な思い入れがあった。それが特別便利なモジュールとは思っていない。そのアルゴリズムは非常に基本的で、私が元々これを書いたプロジェクト以外には、どの製品コードにも使っていない。私は屡々新しいテクニックを試すために、それを使用している。8月9日にバージョン2.00をリリースした（その実装の変更は、メジャーバージョンナンバーを上げることに相応しいと思った）。

昨日、私はMoose使用を止める要望のRTチケットを受取った。そのチケットは、いろいろな使用（そのチケットでは、コマンドラインでの使用に言及しているが）に対して、Mooseによって加わった更なるオーバーヘッドが受け入れ難いパフォーマンスの打撃になっていることを明らかにしている。

私はこれをどのように克服するか分からない。一デベロッパーとして、私はMooseの使用が好きである。Mooseは、Perlでオブジェクト指向のコードを書くことを容易にする。私は、翌年以降年々、CPANデベロッパーはMooseを使っていくだろうと考えている。もし、あなたが既に充分に複雑なことをPerlで書いているなら、Mooseを使っているモジュールを使用するチャンスである。時が経つにつれて、Mooseに依存するPerlコードの割合は増加するだろう。しかし、小さなアプリケーションに対して受け入れ難いパフォーマンスの打撃があるならば、デベロッパーが使っていないMooseを強制することはいいことだろうか？

これをもう少し熟考するまで、私の作物をMooseに移動させる計画を保留したいと思う。しかし、私は他の人の意見を聞きたい。あなたがCPAN作者なら、あなたのモジュールをMooseへ移すことを考えているのか。あなたがアプリケーションデベロッパーなら、Mooseを無理強いするモジュールを避け始めているのか。

あなたの考えを教えてほしい。