2013年 のPerl5 の OOP について考える - tokuhirom's blog
Moo今年の本命? 新しくつくるならこれが無難な気がします。速度的にも Mouse とあまりかわらない。 若干依存がおおい気もするけど、インストールベースがふえれば気にならなくなるかな、ともおもいます。 Class::XSAccessor とかつかってるんで、速度的にもホットスポットは速いのがよい。 なお発音はムーだとおもう。 (http://www.forvo.com/word/moo/) Mouse完成している感じがする。得にわるい点もないが、あえていうと xs 部分がおおいので、gfx 以外がメンテできないかんじがするのが欠点か。 Xslate をつかっている場合は自動的に xslate が mouse つかってるので、自然と Mouse がロードされるので、そういった意味では Mouse つかってもいいかなとおもっている。
perlでデーモン書く時は素直にMoose化しておくのもいいかもな - download_takeshi’s diary
今更Mooseの話題かよ、と思われることでしょうが、自分は常に流行の３年遅れぐらいを全力で追いかけるタイプなので、自分にとっては今が旬。というわけで、Moose的なはなしを書きます。 突然ですが、現役バリバリのperl使いのみなさんに質問です。 POEやらAnyEventやらでちょっとしたアプリケーションサーバを書く場合、みなさんはどうやって「デーモン化」してますか？ 自分はもう何回もこの手のものを書いてきたつもりですが、実は未だにベストな手法を編み出せてません。。。 App::DaemonやDaemon::Genericあたりでなんとなく自分流な形を模索した時期もありましたが、結局どれも面倒くさくなって、最近では「もう nohup perl hoge_server.pl & でいいじゃん」みたいな。「止める時は pkill -f hoge_server でいいじゃん、文句アッカ」みたいな
初めてのCatalyst入門（6） Perlのオブジェクト指向とモデル
はじめに 前回では、フロー制御のメソッドを使用してアクションからURLを遷移することなく別アクションを呼び出す方法、そしてリダイレクトを行う方法を紹介しました。これでコントローラに関する主要な機能についての紹介を終えて、今回からはモデルに移っていきたいと思います。 ところで、Catalystの5.7から5.8にバージョンアップされた際に、内部を実装する仕組みとしてMooseが採用されました。MooseとはPerl5にオブジェクトシステムを導入するためのモジュールであり、これまでのblessを使用したPerlのオブジェクト指向プログラミングよりも簡単に、より多くのことを実現できます。 本記事では、簡単にではありますがblessとMooseを比較したPerlのオブジェクト指向プログラミングについて説明し、その後でモデルの概要を説明していきます。 対象読者 Perlで簡単なスクリプトを作成したこ
Moose::Cookbook::Recipe7 - make_immutable - - 日向夏特殊応援部隊
Moose::Cookbook::Recipe7 - Making Moose fast with immutable - metacpan.org 今度は make_immutable について。 ソース package PointImmutable; use Moose; has 'x' => (isa => 'Int', is => 'ro'); has 'y' => (isa => 'Int', is => 'rw'); __PACKAGE__->meta->make_immutable; package PointNoImmutable; use Moose; has 'x' => (isa => 'Int', is => 'ro'); has 'y' => (isa => 'Int', is => 'rw'); package PointCAF; use base qw(Cla
Mooseの為か、そうでないのか | taro-nishinoの日記 | スラド
私がMooseに関して、そのロード時間を無理矢理無視しているかのように知人から言われました。私は決してMoose信奉者ではありません。現実にはMooseとの併用を考慮して、Mouseまたは Any::Mooseを使う方が最近は多いのです。ましてや、私は実際Mouseに高い評価を与えました（因みに、Mouseの作者がメンテナから降りた時に、私が高いレートを付けた手前、身辺から私は槍玉に上げられました。そこへ、親愛なる藤吾郎氏がメンテナに着任してくださり本当に安心しました）。Jonathan Rockway氏の″何故、私はPerlを続けるのか″にある言葉ではありませんが、エンジニアリングはすべてトレードオフの集まりだと思います。下辺にいる私以上にPerlに未熟な人達が各々自家製クラス生成を作り出す方がよっぽど恐ろしいです。 また、Dave Cross氏の″Mooseを使うか使わないか″に端を発
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
Mooseを使うか使わないか | taro-nishinoの日記 | スラド
私は、以下のような人には理屈もへったくれもなく、無条件にMoose（Mouseでも構いません）を使えと言います。PerlのOOに悩みたくない人、いわゆるモダーンPerlが何であるか理解出来ない人（すなわち、Perlのベストプラクティスやピットフォールを知らない人、もっと端的に言えば、Perlに精通していない、赤ちゃん言葉でしか喋れない人です）、Mooseを知らない人（皮肉で反対なことを言っているのではありません。Mooseを食わず嫌いな人です。そういう人は、どうせMooseやClass::MOPのソースも読みはしないのだから、Mooseの何たるかを理解させる時間が無駄です）。 しかし、Perlに精通している人には無理強いしません。いろいろな考えがあるでしょうし、オーバーヘッドが無視し得ない環境もあるのです。また顧客が望まない場合もあります。一般的に顧客というのはすごく保守的です。コードも納
第6回 Catalyst::Upgrading：検証はお早めに | gihyo.jp
3年前の大混乱 モダンPerl界を代表するウェブアプリケーションフレームワークといわれるCatalystが2006年半ばに5.6系統から5.7系統に移行したとき、創始者のゼバスティアン・リーデル氏を追い出す形で集団管理体制に移行した開発チームが最初にしたことは、プロジェクト開始当初から使われてきたCatalystという名のディストリビューションはそのままに、Catalyst-Runtimeという新しいディストリビューションをつくることでした。 このようなディストリビューション名の変更は、CPANクライアントを使っている分には（内部でモジュール名からディストリビューション名への変換が行われるので）問題にならないのですが、外部のパッケージ管理者たちには少なからぬ負担をかけました。なにしろ突然100を越す関連パッケージの依存が変更になるのです。基本的にはメタ情報だけ書き換えれば済む話とはいえ、従
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
perl-mongers.org