タグ

mooseに関するfbisのブックマーク (36)

  • YappoLogs: Mooseを使うべきでない理由とMooseを使う理由

    Mooseを使うべきでない理由とMooseを使う理由 twitterにでも書いて終りにしようと思ったけど140文字じゃ無理なんで。 Mooseの欠点やら利点やらMouseがどうだとかは今更感過ぎて割愛するし、下手な抽象的な表現も面倒なんでしない。 あなたが、再利用性の高いライブラリを作りたい場合はMooseを使うべきではない。 なぜならMooseはフレームワークだからであるからだ。 たとえ有用な再利用性の高いライブラリを作ったとしても、Mooseというフレームワークに依存してしまっては、あなたの有用なライブラリを選択してもらえない事もあるだろう。 誰かが小さいスクリプトを書くために、あなたが書いた有用なライブラリを使う事で楽が出来るとする、だがMooseというフレームワークに依存したばっかりに、その有用なライブラリの後ろに控えるものの大きさに臆して選択してくれないかもしれない。 もちろんM

  • Mooseの為か、そうでないのか | taro-nishinoの日記 | スラド

    私がMooseに関して、そのロード時間を無理矢理無視しているかのように知人から言われました。私は決してMoose信奉者ではありません。現実にはMooseとの併用を考慮して、Mouseまたは Any::Mooseを使う方が最近は多いのです。ましてや、私は実際Mouseに高い評価を与えました(因みに、Mouseの作者がメンテナから降りた時に、私が高いレートを付けた手前、身辺から私は槍玉に上げられました。そこへ、親愛なる藤吾郎氏がメンテナに着任してくださり当に安心しました)。Jonathan Rockway氏の″何故、私はPerlを続けるのか″にある言葉ではありませんが、エンジニアリングはすべてトレードオフの集まりだと思います。下辺にいる私以上にPerlに未熟な人達が各々自家製クラス生成を作り出す方がよっぽど恐ろしいです。 また、Dave Cross氏の″Mooseを使うか使わないか″に端を発

  • 迷信: Mooseは無用な従属物である | taro-nishinoの日記 | スラド

    以前にも書いたことがありますが、私の周辺でPerlに習熟していない人には理屈もへったくれもなく、Mooseを使うように言ってます。それだけでは暴君なので、Moose::Manual::Unsweetenedあたりを読んでみたらとアドバイスします。これを読んで真意が分かるはずだと思っていました。ところが、後に納得したかと聞くと、逆に反論して来る人もいました。どこで仕入れて来たのか分かりませんが、スタートアップ時間がどうたらこうたら云々。そんなもの達人になってから言えと言いたいところを我慢して、Moose::Manual::Unsweetenedの感想を聞きますと、どうも読んだのかそうでないのかはっきりしません。Moose::Manual::Unsweetenedを私は何回も読み返しているのですが、ちょっとインパクトが弱いように思いました。マニュアルだから刺激が少ないのは当り前です。そこで、何

  • http://perldoc.perlassociation.org/pod/Moose-Doc-JA/

  • Moosification: Catalyst 5.8に移行した際にちょっと気づいた事。 - D-6 [相変わらず根無し]

    Moosification: Catalyst 5.8に移行した際にちょっと気づいた事。 最初からMooseベースでアプリケーションを作るというのは、実務ではなかなか難しいのはわかります。一般論は JPA #02で話すのでおいておきますが(参加申し込みは今日5/12までですよ!)、5.8 からMoose化したCatalystであった問題・注意点をちょっと書き出してみます。 1. use Catalyst Catalyst::Upgradingを読んでいると package MyApp; use Moose; extends 'Catalyst'; __PACKAGE__->setup(qw/ ConfigLoader /); という表記が見られるが、これは気をつけないと駄目。 自分が直面した問題は、path_to()等を使った時に起こった。path_to() は現アプリのルートディレクトリ

    fbis
    fbis 2009/05/12
    まだまだ様子見だな
  • 第4回 Any::Moose:なにがどうでもムースはムース | gihyo.jp

    CPANTSは情報の宝庫 Perlを使う最大の利点といわれるCPANですが、CPANは単なるモジュール置き場ではありません。CPANはまたPerlの利用状況を知るうえで不可欠な統計情報を得る場でもあります。そのような統計情報のいくつかは、いわゆるCPAN検索サイトからも確認できますが、より突っ込んだ情報が欲しい場合はCPANTS(CPAN Testing Service)と呼ばれるサイトを確認するのが便利です。 国内ではnipotanこと谷口公一氏が始めた「輝け!全日最強 CPAN Author 決定選手権」のネタ元として知られていますが、このサイトでは個々の作者やモジュールの品質だけでなく、そのモジュールが実際にどこで使われているかという情報を得ることもできます。 たとえば前回取り上げたロール関連のモジュールの利用状況を調べてみると、古き良きExporterを依存モジュールとして取り上

    第4回 Any::Moose:なにがどうでもムースはムース | gihyo.jp
  • 第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

    第3回 Moose::Role:役割単位のクラス分け | gihyo.jp
  • Moose(Mouse)の基本。アクセサのコードを読んでみる

    「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧

    Moose(Mouse)の基本。アクセサのコードを読んでみる
  • 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され

  • MooseのTypeConstraintsのインターフェイスがよくない - Islands in the byte stream (legacy)

    Moose::Util::TypeConstraintsのSYNOPSISより: use Moose::Util::TypeConstraints; type 'Num' => where { Scalar::Util::looks_like_number($_) }; subtype 'Natural' => as 'Int' => where { $_ > 0 }; subtype 'NaturalLessThanTen' => as 'Natural' => where { $_ < 10 } => message { "This number ($_) is not less than ten!" }; このasやらwhereやらは一見すると名前付き引数に見えるが,現状では実際には単なるシンタクスシュガーでしかない。定義は以下の通り。 sub as { @_ } sub from

    MooseのTypeConstraintsのインターフェイスがよくない - Islands in the byte stream (legacy)
    fbis
    fbis 2009/01/08
    多分、見た目のかっこよさ(?)的なものを表現したかったのだと思う。
  • 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が速いわけ - Islands in the byte stream (legacy)
  • Catalyst 5.7 vs 5.8でベンチマークを取ってみた - とほほのN88-BASIC日記

    CPANにMoose版Catalystである5.8のdeveloper releaseが出ていたのでベンチマーク取って見ました。 なお、Catalyst::ClassDataがパッケージに含まれていなかったので、これだけリポジトリから持ってきて動かしてます。 テスト内容はcataltst.pl MyAppで出来るトップページをビルトインエンジンで起動して ab -n 1000 -c 100 http://localhost:3000/するだけ。 結果はこちら。 Catalyst 5.7014 Server Software: Server Hostname: localhost Server Port: 3000 Document Path: / Document Length: 5635 bytes Concurrency Level: 100 Time taken for tests:

    Catalyst 5.7 vs 5.8でベンチマークを取ってみた - とほほのN88-BASIC日記
  • Moose - Perl5のためのまったく現代的なオブジェクトシステム

    NAME SYNOPSIS CAVEAT DESCRIPTION 別のオブジェクトシステム!?!? これを製品に使えますか?それとも実験段階でしかありませんか? MooseはPerl 5におけるPerl 6に過ぎませんか? BUILDING CLASSES WITH MOOSE EXPORTED FUNCTIONS UNEXPORTING FUNCTIONS unimport MISC. What does Moose stand for?? CAVEATS ACKNOWLEDGEMENTS SEE ALSO BUGS AUTHOR COPYRIGHT AND LICENSE DOCUMENT TRANSLATION Page Top NAME Moose - Perl5のためのまったく現代的なオブジェクトシステム Page Top SYNOPSIS package Point; use

    fbis
    fbis 2008/10/01
    古いバージョンの日本語ドキュメントなので注意が必要
  • hasの定義を取得する - Unknown::Programming

    hasで定義したメソッドのオーバーライドについて - Unknown::Programmingの続きというか。 さて、先日の記事でhasで宣言する時にアクセサの先頭に+をつければ特定のものだけを上書きできることを知ったのですが、そんな便利なものがあるとは知らずに(MooseのPODに書いてたねorz。翻訳版しか見てなかった)作ってしまったものがあるのでとりあえず折角なのでコードだけ張っつけときます。 要はどういうhasで定義されたものかを取得できればいいなぁーと思ったので、ズバリどういうhasで定義されたものかを取得するものを試しに作ってみたわけなのです。 package MooseX::HasRestructure; use strict; use warnings; our $VERSION = 0.01; our @EXPORT_LIST = qw/ has_restructure

    hasの定義を取得する - Unknown::Programming
  • lazyなdefault再呼び出し - Unknown::Programming

    metaクラスからたどって直接呼び出した方がわかりやすいんではないかと思ったりしました。 package Foo; use Moose; has hoge => ( is => 'rw', lazy => 1, default => sub { 100 }, ); __PACKAGE__->meta->make_immutable; 1; package main; use strict; use warnings; my $foo = Foo->new; print $foo->hoge . "\n"; #=> 100 $foo->hoge(200); print $foo->hoge . "\n"; #=> 200 $foo->hoge($foo->meta->get_attribute_map->{hoge}->default->()); print $foo->hoge . "\n

    lazyなdefault再呼び出し - Unknown::Programming
  • hasで定義したメソッドのオーバーライドについて - Unknown::Programming

    defaultだけ上書きとかできないのかな? package Foo; use Moose; has foo => ( is => 'rw', lazy => 1, default => sub { 100 } ); package Bar; use Moose; extends qw(Foo); # isとlazyを引き継いで欲しい! has foo => ( default => sub { 200 } ); 派生先でdefaultだけ上書きしたいんだけどそーゆーのはできない? やっばhasの定義をBarに全コピーするのがいいのかなぁ。でも定義が重複するのがやだな・・・。triggerとかが二重化しちゃうし。 んー他にはこうするとか? package Foo; use Moose; has foo => ( is => 'rw', lazy => 1, default => sub {

    hasで定義したメソッドのオーバーライドについて - Unknown::Programming
  • Moose使ってると初期処理って殆どいらんねって思えてきた - Unknown::Programming

    Moose使い始めの頃はBUILD用意してそこで初期処理してたんだけど、慣れてくるとhasのlazyとdefaultでその殆どを賄える事に気付いた。 よくよく考えたら初期処理って引数のハッシュを解析してそのキー毎に特殊な処理をさせるだけが多いのでhasで定義しとけばその辺の処理が必要なくなる。 それだけじゃなくてcoerce使えば型変換も自動でやってくれるから自分で実装する必要が無い。 それに後から値を変更する場合にはhasのtriggerがあるのでそれでいいし。 アホ程コードが減る。今更だけど。いやぁ凄い。 Moose凄い。 Moose嫌い。 Moose憎い。 俺が今まで試行錯誤工夫してやってきたことを全部やっちゃうなんて! 酷いよMoose!

    Moose使ってると初期処理って殆どいらんねって思えてきた - Unknown::Programming
  • Mooseでdefaultをもう一度呼ばせる方法 - Unknown::Programming

    package Foo; use Moose; has aaa => ( is => 'rw', lazy => 1, default => sub { 100 }, ); no Moose; __PACKAGE__->meta->make_immutable; 1; package main; use Perl6::Say; use Foo; my $foo = Foo->new; say $foo->aaa; # 100 delete $foo->{aaa}; # delete! say $foo->aaa; # 100 メンバ変数として使用されているハッシュのキーをdeleteで削除することでもう一度defaultを呼ばせることができる。$foo->aaa(undef)とかじゃダメ。 同じオブジェクトでdefaultを再び呼びたいケースなんてなんだか設計ミスってそうな気もしないことも

    Mooseでdefaultをもう一度呼ばせる方法 - Unknown::Programming
  • MooseにDBIx::Class型を用意したいとか。 - Unknown::Programming

    DBIx::Class型というかsearch等で取ってきたDBIx::Class::Rowと言えばいいのかな。 雰囲気としてはこんな感じの package Foo; use Moose; use Moose::Util::TypeConstraints; use MySchema; my $schema = MySchema->connection($info); class_type 'MySchema::UserMst'; coerce 'MySchema::UserMst' => from 'HashRef', => via { $schema->resultset('UserMst')->new_result($_); }; has user_data => ( is => 'rw', isa => 'MySchema::UserMst', coerce => 1, ); my $

    MooseにDBIx::Class型を用意したいとか。 - Unknown::Programming
  • Mooseのwithってクラス名を省略できないのかな? - Unknown::Programming

    ちょっとした疑問。 Mooseでwithするときに、例えば package MyClass; use Moose; with qw{ FooFooFoo::BarBarBar::BazBazBaz::Role::Base FooFooFoo::BarBarBar::BazBazBaz::Role::Hoge FooFooFoo::BarBarBar::BazBazBaz::Role::Muge FooFooFoo::BarBarBar::BazBazBaz::Role::Pugera MooseX::Foo MooseX::Bar }; みたいな感じになっててちょーメンドイ。 とりあえず package MooseX::WithIn; use strict; use warnings; sub import { my $pkg = caller; my $with = $pkg->can(

    Mooseのwithってクラス名を省略できないのかな? - Unknown::Programming