問題タブ [moose]

ビルダーメソッドの失敗を処理する最良の方法は何ですか?

例えば：

がハンドルを取得できなかった場合_build_file_handle、ビルダーは を返しundefますが、これは型制約に失敗します。

型制約で共用体を使用して、有効な値としてfile_handlean を受け入れることができます。undefただし、値が であっても、述語has_file_handleは true を返しますundef。

ビルダーが失敗したことを通知する方法はありますか?属性をクリアしたままにする必要がありますか?

Moose を使用するパッケージを編集していますが、タグ リストに Moose 属性を表示させるためのプラグインがあるかどうか疑問に思っていました。

たとえば、次のコードでは、属性optionsは Tag_List に表示されませんが、表示されますprint_out_site。

Mooseで使用する場合、Log4perlに、常に行番号99のメソッド::委任ではなく、ログイベントの行番号とパッケージ/クラスを正しく表示させることは可能ですか？

私の場合、属性isa Log :: Log4perl :: Loggerを作成し、さまざまなログレベル（log、warn、error、...）をクラスに委任しました。これを行うと、Delegation.pmもファイルとして表示されます。

ありがとう！

この単純なクラスを考えてみましょう。

そして、このコード：

コードは、型制約の失敗に関する大きなエラーメッセージで終了します。

情報を取得するためにエラー文字列を解析することなく、失敗した属性（ foo）、理由（失敗した型制約）、および渡された値（）を抽出できるようにしたいと思います。Not an Int

このようなもの：

これは可能ですか？これを実現できるMooseXディストリビューションはありますか？さらに良いことに、これを可能にする、私が見逃したいくつかのMoose機能はありますか？

更新：私は特に型の制約に興味がありますが、他のMooseエラーも非常に良いでしょう。また、。を使用してオブジェクトをスローできることも認識していますdie。したがって、私が作成するコードで例外を構造化するのは比較的簡単です。

私は厳密にテスト駆動開発を始めたいと思っています。しかし、Moose と MooseX::FollowPBP によって生成されたメソッドをどの程度テストする必要があるのか​​疑問に思っていました。たとえば、次のクラスがあります。

私の現在のテストスクリプトは次のとおりです。

これは十分なテストですか、それとも過剰なテストですか? (つまり、正規表現の明らかに欠落しているテスト以外に)。

これについてどこかでウェブページか別の投稿を見たと思ったのですが、今日は見つけられませんでした。

Moose のクラスを受講するのはちょっと面倒なようです。次に、DBIx::Classを使用して結果セットを取得し、結果セットをムース クラスに手動でマップします。

Moose::Manual::MooseXの現在のバージョン (0.98)から次の行があります。

MooseX::Method::Signaturesと の将来に大きな期待を寄せています MooseX::Declare。ただし、これらのモジュールは、コミュニティの一部の非常識なメンバーによって本番環境で定期的に使用されていますが、下位互換性のない変更を行う必要がある場合に備えて、まだアルファとしてマークされています。

MooseX::Method::Signatures2009 年 9 月の変更ログで、「怖い ALPHA 免責事項」の削除について言及されていることに気付きました。
それで、これらはまだ「アルファ」ですか？
私はまだそれらを使用する「より狂った」人の一人と見なされますか?

MooseX::Method::Signaturesについては多くの話題があり、それ以前にも、メソッドや関数のすべての引数を型チェックするように設計されたParams::Validateなどのモジュールが話題になっています。個人的にも職場でも、将来のすべての Perl コードに前者を使用することを検討しています。しかし、それが努力する価値があるかどうかはわかりません。

私が見た (そして書いた) すべての Perl コードは、そのようなチェックを実行していません。モジュールがこれを行うことはめったにありません。

use warnings;おそらく、ある種のヘルパー モジュールがないと単純に作業が多すぎるためですが、実際には、関数に余分な引数を送信したり、スカラーを期待するメソッドに配列参照を送信したりしないためです。私たちはすぐにそれについて耳にします - ダックタイピングアプローチ.

では、Perl の型チェックはパフォーマンス ヒットに値するものでしょうか? それとも、C や Java などのコンパイルされた厳密に型指定された言語で主にその強みが発揮されるのでしょうか?

これらのモジュールを使用する Perl を書いた経験があり、それらの使用による利点 (または利点) を見た人からの回答に興味があります。会社/プロジェクトに型チェックに関するポリシーがある場合; 型チェックとパフォーマンスに関する問題。

更新:最近、 Strong Testing vs. Strong Typingという興味深い記事を読みました。わずかな Python の偏見を無視して、本質的には型チェックが場合によっては窒息する可能性があり、プログラムが型チェックに合格したとしても、それが正確であることを保証するものではないと述べています。

Moose は初めてで、DBIx::Class で使用しようとしています。基本的な DBIC のクエリと更新は機能しますが、属性を変更すると、書き込もうとしたトリガーが実行されません。

'isin' print 'FOO' のトリガーが表示されることを期待していますが、何も起こりません。パッケージから DBIx::Class を取り除くと、トリガーは期待どおりに実行されます。

DBIx::Class がトリガーの発火を妨げるような方法で値を設定していると思われます。

残念ながら、Moose での DBIx::Class の使用に関するリソースを見つけることができませんでした。私が書いたものは、ほとんどDBIx::Class と Mooseで見つけたものに基づいています。

DBIx::Class や Moose を間違って使用していますか? Mooseで使用すべき別のORMはありますか?

起動しないトリガーを含むパッケージ: