Moose::Manual::MooseXの現在のバージョン (0.98)から次の行があります。
MooseX::Method::Signaturesと の将来に大きな期待を寄せていますMooseX::Declare。ただし、これらのモジュールは、コミュニティの一部の非常識なメンバーによって本番環境で定期的に使用されていますが、下位互換性のない変更を行う必要がある場合に備えて、まだアルファとしてマークされています。
MooseX::Method::Signatures2009 年 9 月の変更ログで、「怖い ALPHA 免責事項」の削除について言及されていることに気付きました。
それで、これらはまだ「アルファ」ですか？
私はまだそれらを使用する「より狂った」人の一人と見なされますか?
それらは本番環境に対応していると思います-私はそれらを本番環境で使用しています-しかし、考慮すべき点がいくつかあります。
MooseX::Declare依存関係は、コンパイル時にほとんどすべての魔法を実行します。プログラムのサイズによっては、0.5 秒から数秒の追加の初期化オーバーヘッドが発生する場合があります。これが問題になる場合は、 MooseX::Declareを使用しないでください。
実行時の主なオーバーヘッドは型と引数のチェックです。これは (理想的には) とにかく実行する必要があります。とはいえ、Moose 型の制約にはいくつかのオーバーヘッドがあります。具体的には、強制と、より複雑な (MooseX::Types::Structured-style) 制約です。パフォーマンスが問題になる場合は、これらを使用しないでください。
MooseX::DeclareとMooseX::Method::Signature の外部構文が安定しました。しかし、内部が極端に変化する可能性があることを知っておくことは重要です。（幸いなことに、良い方向に変化します）
お分かりいただけると思いますが、署名自体は、Perl トークナイザー (toke.c) から盗まれた C コードの大きなブロックを使用して取得されます。実際には何も解析していないため、状況によってはこれが壊れる可能性があります。角かっこ内のビットは、純粋な Perl 用に設計されたPPIを使用して解析されますが、結果の PPI ツリーはハッキングされて、有用なものが取得されます。Devel::Declare自体がハックです。特定のキーワード (「role」、「class」、「method」など) を見た後、Devel::Declare を使用するモジュールは、ソース コードを手動で書き換える必要があります。 Perl パーサー。
まれなケースでは、Perl が segfault を起こす可能性があります。または、ソース コードを書き直すと、構文エラーが発生しますが、.xml がないと原因がわかりません-MO::Deparse。誤ってMooseX::Declare構文を間違えた場合、モジュールがこれを検出して適切なエラーを返すという保証はありません。ALPHA メッセージはなくなったかもしれませんが、これはまだ内部的に暗く恐ろしいことを行っているため、それに備えておく必要があります。
アップデート
MooseX::Declare はあまり更新されていないため、Moopsなどの代替手段を検討することをお勧めします。個人的には、Perl 自体がクラス/メソッド/構文をネイティブにサポートし始めるまで、純粋な Moose を使い続けることにしました。
それは何よりも視点の違いの問題だと思います.raflは前述の「コミュニティのより狂ったメンバー」の1人ですが、Rolskyはより保守的です. 誰に同意するかはあなた次第です。実際、最も重要な変数はあなた自身のコードだと思います。
MooseX::Declare は良いコードです。マシンを無作為に爆破することはなく、パフォーマンスも悪くないし、多くの気の利いた機能を提供すると同時に、作成しなければならないボイラープレートの量を減らします。ただし、将来変更される可能性があり、コードが更新されるまでコンパイルを拒否する可能性があります。エディタや他の開発ツールが解析できない構文を見つけたときに混乱するかもしれませんし、あなたのコードで動作する新しいモジュールを学習させて共同作業者を怒らせるかもしれませんし、それを作って上司を怒らせるかもしれませんしたがって、将来のメンテナーは、コードを操作するために新しいモジュールを学習する必要があります。それらのうちどれがあなたに当てはまり、どの程度まで当てはまりますか? あなたは私よりもよく知っていると思います。
それが基づいているの成熟度と安定性、あるいはそれMooseX::Delcare自体でさえ、まだ「プライムタイム」の準備ができていないと感じる人がいます。また、月に数百万人の訪問者がいる2つの大企業が、本番環境にいることも知っています。私は個人的に提供されたスタックに満足しており、まだ持ち込む必要はないと考えています。私は、からの宣言型の砂糖なしで新しいコードを書くことを拒否する人を深く尊敬している意見を持っている人々を知っています。Devel::DeclareMooseMooseX::DeclareMooseMooseX::DeclareMooseX::Declare
つまり、本番環境に対応しているかどうかの判断は、本番環境、開発ニーズ、およびリスクの好みに大きく依存します。あなたの立場に立たなければ、与えられたツールがそのプロファイルにどれだけ一致するかについて、情報に基づいた決定を下すことはできません。
MooseX::Method::Signatures (MXMS)、およびそれを使用する MooseX::Declare は、本番環境に対応していません。これは、コードが安定していないからではなく、非常に遅いからです。methodタイプや引数を使用せずにキーワードを使用するだけで、通常のメソッド呼び出しよりも 500 ～ 1000 倍のランタイム パフォーマンス ヒットになります。私の Macbook Pro は、単純な Perl では 5,000,000 であるのに対し、MXMS では 1 秒あたり約 6,000 の単純なメソッド呼び出しを実行できます。
対照的に、 Method::Signaturesは、要求されたチェックを実行するために通常かかるコストを超えるパフォーマンス ヒットはほとんどありません。構文は MXMS とほぼ同じで、Moose (および Mouse) タイプをサポートしています。どちらも、同じ基本的な構文変更手法に依存しています。(完全な開示、私は Method::Signatures の作成者です。)
MooseX::Declare が好きで Method::Signatures のパフォーマンスが必要な場合は、Method::Signatures::Modifiersを試してください。
「生産準備完了」の意味によって異なります。彼らの速度がかなり遅くなるまで、私は彼らに依存しません. 私は、外部コードの変更や API の調整などによる頻繁なケアを必要としない本番環境が好きです。これは Moose に限ったことではなく、若いプロジェクトなら誰でもできることです。
それがあなたにとってどれほど重要かを判断する必要があります。状況によっては、製品を本番環境にプッシュするのに時間がかかることがあるため、そのような作業には慎重になる必要があります。反対に、本番サーバーでファイルを直接編集できる場所もあります。つまり、特定の MooseX モジュールがどちら側にあるのかを誰かが知る前に、許容範囲を定義する必要があります。
MooseX::Declareうまく機能しMooseX::Method::Signaturesていますが、コードの動作によっては非常に厄介なペナルティが発生する可能性があります。methodこれは、キーワードを使用しないか、を使用するだけで修正できますMethod::Signatures::Modifiers。
私が見ているパフォーマンスの低下は、比較して約 2 ～Method::Signatures::Modifiers5 倍です (5 倍は主に、私が使用していた特定のクラスの場合です)。そして、計算が長くなると2倍以下になるため、ほとんどがコンパイル時または最初の初期化のようです。
Method::Signatures::Modifiersより良いエラーがありますが、デバッガーを使用するときはこの最適化をオフにする必要があります (これらのメソッドが表示されないため、問題が発生します-MO=Deparse。出力で確認できます)。
Perl の議論を変える地獄を取り除くことは価値があるかもしれません。