%26utm_content%3Dlivedoor)
YappoLogs: Mooseを使うべきでない理由とMooseを使う理由
Mooseを使うべきでない理由とMooseを使う理由 twitterにでも書いて終りにしようと思ったけど140文字じゃ無理なんで。 Mooseの欠点やら利点やらMouseがどうだとかは今更感過ぎて割愛するし、下手な抽象的な表現も面倒なんでしない。 あなたが、再利用性の高いライブラリを作りたい場合はMooseを使うべきではない。 なぜならMooseはフレームワークだからであるからだ。 たとえ有用な再利用性の高いライブラリを作ったとしても、Mooseというフレームワークに依存してしまっては、あなたの有用なライブラリを選択してもらえない事もあるだろう。 誰かが小さいスクリプトを書くために、あなたが書いた有用なライブラリを使う事で楽が出来るとする、だがMooseというフレームワークに依存したばっかりに、その有用なライブラリの後ろに控えるものの大きさに臆して選択してくれないかもしれない。 もちろんM
第6回 Catalyst::Upgrading：検証はお早めに | gihyo.jp
3年前の大混乱 モダンPerl界を代表するウェブアプリケーションフレームワークといわれるCatalystが2006年半ばに5.6系統から5.7系統に移行したとき、創始者のゼバスティアン・リーデル氏を追い出す形で集団管理体制に移行した開発チームが最初にしたことは、プロジェクト開始当初から使われてきたCatalystという名のディストリビューションはそのままに、Catalyst-Runtimeという新しいディストリビューションをつくることでした。 このようなディストリビューション名の変更は、CPANクライアントを使っている分には（内部でモジュール名からディストリビューション名への変換が行われるので）問題にならないのですが、外部のパッケージ管理者たちには少なからぬ負担をかけました。なにしろ突然100を越す関連パッケージの依存が変更になるのです。基本的にはメタ情報だけ書き換えれば済む話とはいえ、従
迷信： Mooseは無用な従属物である | taro-nishinoの日記 | スラド
以前にも書いたことがありますが、私の周辺でPerlに習熟していない人には理屈もへったくれもなく、Mooseを使うように言ってます。それだけでは暴君なので、Moose::Manual::Unsweetenedあたりを読んでみたらとアドバイスします。これを読んで真意が分かるはずだと思っていました。ところが、後に納得したかと聞くと、逆に反論して来る人もいました。どこで仕入れて来たのか分かりませんが、スタートアップ時間がどうたらこうたら云々。そんなもの達人になってから言えと言いたいところを我慢して、Moose::Manual::Unsweetenedの感想を聞きますと、どうも読んだのかそうでないのかはっきりしません。Moose::Manual::Unsweetenedを私は何回も読み返しているのですが、ちょっとインパクトが弱いように思いました。マニュアルだから刺激が少ないのは当り前です。そこで、何
Results from JPA sponsorships of Moose/Class::MOP - Islands in the byte stream (legacy)
Moose/Class::MOP開発スポンサー (JPA Sponsors Moose/Class::MOP Work)の報告です。 まずは現状ですが，Moose 0.90/Class::MOP 0.93のロード時間が約176msであるのに対し，ベースラインとしたMoose 0.88/Class::MOP 0.89のロード時間が約209msであるので，約18%高速になっています。当初の目的が20%以上であるので，目標値には達しなかったことになります。しかし，現状では作成中のブランチすべてが取り込まれたわけではないため，ゆくゆくはさらに高速になる見込みです。 今回行った高速化に大きく寄与したのは次の二点です。 ボトルネックであったget_method_map()をできるだけ使わないようにした(C::MOP) C::MOPが生成するコードの一部を手で展開し，実行時evalを減らした(C::MO
Mooseを使うか使わないか | taro-nishinoの日記 | スラド
私は、以下のような人には理屈もへったくれもなく、無条件にMoose（Mouseでも構いません）を使えと言います。PerlのOOに悩みたくない人、いわゆるモダーンPerlが何であるか理解出来ない人（すなわち、Perlのベストプラクティスやピットフォールを知らない人、もっと端的に言えば、Perlに精通していない、赤ちゃん言葉でしか喋れない人です）、Mooseを知らない人（皮肉で反対なことを言っているのではありません。Mooseを食わず嫌いな人です。そういう人は、どうせMooseやClass::MOPのソースも読みはしないのだから、Mooseの何たるかを理解させる時間が無駄です）。 しかし、Perlに精通している人には無理強いしません。いろいろな考えがあるでしょうし、オーバーヘッドが無視し得ない環境もあるのです。また顧客が望まない場合もあります。一般的に顧客というのはすごく保守的です。コードも納
Mooseの速度が遅いという議論のまとめと感想 - Islands in the byte stream (legacy)
Adam Kennedy (ADAMK)が「Array::CompareでMooseを使わないようにしてくれ」とRTでチケットを作成したことがきっかけとなり，Mooseの速度について議論が起きています。以下ラフなまとめ。 #49270: Remove the use of Moose - RT Array::CompareではMooseを使わないでほしい。Mooseを使いつづけるならばコマンドラインアプリケーションでは使うに堪えないし，PadreでもArray::Compare依存をなくすつもりだ。 Moose or No Moose - Perl Hacks (Array::Compareの作者ブログ) 最近いくつかのモジュールをMoose化しはじめたのだが，「Mooseを使うな」と言われてしまった。Mooseは楽なので使い続けたいが，どうしたものか。 Re: Moose Or No M
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
第4回 Any::Moose：なにがどうでもムースはムース | gihyo.jp
CPANTSは情報の宝庫 Perlを使う最大の利点といわれるCPANですが、CPANは単なるモジュール置き場ではありません。CPANはまたPerlの利用状況を知るうえで不可欠な統計情報を得る場でもあります。そのような統計情報のいくつかは、いわゆるCPAN検索サイトからも確認できますが、より突っ込んだ情報が欲しい場合はCPANTS（CPAN Testing Service）と呼ばれるサイトを確認するのが便利です。 国内ではnipotanこと谷口公一氏が始めた「輝け！全日本最強 CPAN Author 決定選手権」のネタ元として知られていますが、このサイトでは個々の作者やモジュールの品質だけでなく、そのモジュールが実際にどこで使われているかという情報を得ることもできます。 たとえば前回取り上げたロール関連のモジュールの利用状況を調べてみると、古き良きExporterを依存モジュールとして取り上
第3回 Moose::Role：役割単位のクラス分け | gihyo.jp
多重継承しないほうがよい場合 前回は多重継承を利用してクラスを拡張するときにありがちな問題と、そのひとつの解決策を見てきましたが、クラスにいくつかのメソッドを追加したいだけであれば、むしろ継承を利用しないほうがふさわしい場合もあります。 たとえば「コウモリ」というクラスを実装するとき、「乳を出す」というメソッドのために「ほ乳類」というクラスを、「空を飛ぶ」というメソッドのために「鳥類」というクラスを継承するのは――たしかにそれで当座の問題は解決するかもしれませんが――違和感が残ります。 use strict; use warnings; use Test::More tests => 4; package Mammal; sub new { bless {}, shift; } sub produce_milk { print "I can produce milk.\n"; } pa
Any::Mooseの挙動と使い方 - Yappo::タワシ
追記 この記事は Any::Moose 0.02 以前が対象です。 0.03および、現在の最新版 0.04 では MouseとMooseを挟んだ処理の挙動が以下のように変わってます。 $VAR1 = bless( { 'roles' => [], 'superclasses' => [ 'Mouse::Object' ], 'name' => 'ANY', 'attributes' => {} }, 'Mouse::Meta::Class' ); $VAR1 = bless( { 'roles' => [], 'superclasses' => [ 'Mouse::Object' ], 'name' => 'ANY2', 'attributes' => {} }, 'Mouse::Meta::Class' ); ようするに最初にuse Any::Mooseをした時にMooseがloadされ
Delegationを使わないでNon-Mooseクラスを継承 - とほほのN88-BASIC日記
FAQにもあるけど、Moose::Objectも継承して->meta->new_objectを明示的に呼ぶことにより、delegationを使わないでNon-Mooseクラスを継承することもできる。 use strict; use warnings; { package Parent; sub new { my ($class, %args) = @_; bless {name => $args{name}}, $class; } } { package Child; use Moose; extends qw(Parent Moose::Object); no Moose; sub new { my $class = shift; my $obj = $class->SUPER::new(@_); return $class->meta->new_object( __INSTANCE__
Moose（Mouse）の基本。アクセサのコードを読んでみる
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
さっきの記事のShikaのベンチのコード - Unknown::Programming
モジュールがMoose依存してた。別れたい… - Unknown::Programming id:tokuhiromさんにベンチうｐ頼まれたんだけども超個人的なBenchmarkコードなのでそのままCodeReposにあげれるような代物でもないということもあり取り急ぎエントリとしてあげておきますので自由に変更しちゃってください。 #!/usr/local/bin/perl -w use strict; use warnings; package MooseBuild; use Moose; has userid => ( is => 'rw', ); has agent => ( is => 'rw', required => 1, ); sub BUILD { my $self = shift; $self->userid(90); $self->userid($self->agent-
モジュールがMoose依存してた。別れたい… - Unknown::Programming
さて毎年年末が近づくとブログ更新頻度が下がるid:fbisですが、Mooseも馴染んできたところなのでそろそろMooseに対して一言いっておくかということでね、はい。 Mooseは素晴らしい。とてもベリー素晴らしい。何より人に優しい。人間に優しい。 がっ！しかし、Mooseはまだ使うには早すぎた。ナウシカの巨神兵ばりに早すぎたんだ。 実際に組み込んでみて感じた問題点。 大きく分けて二つ。 その壱：オブジェクト生成のコスト やはりなんといってもnewのコストが高い。遅い。 一つ一つを見ればそこそこなんだけどやはりnewのコストは高い。 Mooseを使うのであれば極力newを避けるような仕組みの中に取り入れないと微妙。Catalystで例えるならsetupの時点でnewして以後キャッシュされるような実装だ。 newさえ終わればあとは（複雑なMooseの使い方をしてない限り）それほど問題ではない
Mooseが速いわけ - Islands in the byte stream (legacy)
Mooseは起動に異様に時間はかかるし，クラス階層が複雑でどこから読み始めたらいいのかわからなかったのですが，使い始めるとなるほどこれはすばらしい。しかも，実行速度についてはかなり高速なんですね*1。 なぜ速いのかは追いきれてませんが，Memoizeしたりインライン展開したりしてるみたいです。Class::MOPを読んでいると，こんな感じのinline_xxx()が沢山ありました。 package Class::MOP::Instance; # ... sub is_inlineable{ 1 } # ... sub inline_slot_access { my ($self, $instance, $slot_name) = @_; sprintf "%s->{%s}", $instance, $slot_name; } # ... なるほど，インライン化を駆使すれば速くなって当然です
Moose触ってみるよ！ - Unknown::Programming
触るんかい！ と、言うことで使ってないうちからあれこれ言うのは愚の骨頂ってことでちょっち実務で使ってみるね！少しだけだけど。 でいつもの事ながら組み込むとなればやはり気になるのがパフォーマンス。もう散々書かれてるけど自分で試さないと気がすまないのでベンチ。 #!/usr/local/bin/perl -w package UseMoose; use Moose; has userid => ( is => 'rw' ); has agent => ( is => 'rw', isa => 'Defined' ); sub BUILD { my $self = shift; $self->userid( 90); $self->userid( $self->agent->user_id ) unless $self->agent->is_non_mobile; } package NoMoo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.eorzea.asia/2010/02/post_91.html
perl-mongers.org
http://perldoc.perlassociation.org/pod/Moose-Doc-JA/