Mouseに関する4つの誤解 - Articles Advent Calendar 2010 Hacker
メリクリ！Hacker Trackもいよいよ最終日となりました！ 今回は以下のようなMouseに関するよくある誤解を晴らそうと思います*1。 MouseはMooseとの互換性に難がある Mouseは依存モジュールが多い Mouseはロードが遅い Mouseは実行が遅い MouseはMooseとの互換性に難がある これは誤解です。確かにMouseはMooseと互換性のない部分もありますが、それはほとんどがメタオブジェクトプロトコルレベルの話です。メタオブジェクトプロトコルは普通に使っている限り意識する必要のないものなので、ほとんどのケースでは問題になりません。普通に使う限りは非互換な点は特にないでしょう。 Mouseは依存モジュールが多い これは誤解です。Mooseは大量の依存モジュールがありますが、Mouseが依存しているのは標準モジュールのみです。また、CコンパイラがあればXSコードをビ
first impression of Moo.pm - tokuhirom's blog
construct from reusable modules. THIS IS GOOD.no built-in TypeConstraintsno Role compositionuse warnings ':Fatal'; ...no MOP;といったところ。 Mouse にくらべてどうか、という点については mst が指摘しているとおり less XSmaintainablebuilt on CPAN modules.といった点ではメリットがあるかな、とおもう。 一方で Mouse についていえば more compatibility with moosefastmore features.といった点においてはメリットがある。 さて、はて。
第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
Moose 1.00 is released
With help from Florian Ragwitz and all the rest of the Moose contributors, I just uploaded Moose 1.00 and Class::MOP 1.00 to the CPAN! And I am proud to say that over the last eight months or so, I have barely contributed more then a handful of lines of code to the project. This is not to say that I have abandoned it, but that it has now moved beyond me and is truly a community driven and develope
Type as State, Coercion as Hook - Islands in the byte stream (legacy)
MooseのTypeConstraintは，型というよりはあるデータの性質を表現したものだと考えられる。また，TypeCoercionは，ある型（＝あるデータの性質）に対してフックを掛けるメカニズムと考えられる。 このように考えると，Coercionを利用していろいろと面白いことができるのではないかと思う。 たとえば，以下のようにCoercionを利用してエンコーディングを推測することができる*1。 #!perl package E; use Any::Moose; use Any::Moose '::Util::TypeConstraints'; use Encode qw(encode decode FB_QUIET); subtype 'UniStr', as 'Str', where { utf8::is_utf8($_) }; # define types represent a
迷信： Mooseは無用な従属物である | taro-nishinoの日記 | スラド
以前にも書いたことがありますが、私の周辺でPerlに習熟していない人には理屈もへったくれもなく、Mooseを使うように言ってます。それだけでは暴君なので、Moose::Manual::Unsweetenedあたりを読んでみたらとアドバイスします。これを読んで真意が分かるはずだと思っていました。ところが、後に納得したかと聞くと、逆に反論して来る人もいました。どこで仕入れて来たのか分かりませんが、スタートアップ時間がどうたらこうたら云々。そんなもの達人になってから言えと言いたいところを我慢して、Moose::Manual::Unsweetenedの感想を聞きますと、どうも読んだのかそうでないのかはっきりしません。Moose::Manual::Unsweetenedを私は何回も読み返しているのですが、ちょっとインパクトが弱いように思いました。マニュアルだから刺激が少ないのは当り前です。そこで、何
優しいMoose入門 | taro-nishinoの日記 | スラド
MooseのメインメンテナであるDave Rolsky氏が、Mooseマニュアルを執筆する際、The Perl Foundationから資金を受けるため、その申請書の内容がTPFのホームページで公開されましたが、私はそれを読んで「是非とも氏に書いていただきたい」と思い、絶対に申請を認可させるのだという強い信念（又は勝手な思い込み）で、下手な英語で推薦コメントを書いたことがありました。他のプロジェクトの申請もあったのですが、それらには目もくれませんでした。そのような思い出があるので、Moose::Manualには他人以上に思い入れがあります。そして、内容的にも、さすがRolsky氏、ツボを押さえていて、Moose入門の必読書だと思います。 しかし、世の中にはいろいろな人がいて、Moose::Manualでも敷居が高いと感じるようです。入門の入門があればなぁ、と思っていたところへ、Jan Ku
To Moose Or Not To Moose - D-6 [相変わらず根無し]
To Moose Or Not To Moose I'm just going to wear my Japan Perl Association Head Director's hat for a bit and add a small, but what I consider to be something very important about the whole Moose or no Moose argument: "Moose Developers, please act like you care (more) about startup cost, use of RAM, and other efficiency issues." Here's what I mean by the above: I'm an engineer. I like Moose. I under
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に精通している人には無理強いしません。いろいろな考えがあるでしょうし、オーバーヘッドが無視し得ない環境もあるのです。また顧客が望まない場合もあります。一般的に顧客というのはすごく保守的です。コードも納
A note about the method generator mechanism on Moose - Islands in the byte stream (legacy)
Moose/MOPにおいて，メソッド生成に関わるクラスは以下の通り。 Instance オブジェクトインスタンスへのアクセスを抽象化するクラス インスタンスへアクセスするもっとも低水準なAPIを提供 Method メソッド一般を表すベースクラス Method::*(Method::Accessor, Method::Constructor, etc.) 特殊なメソッドを表すクラス群 Instanceが提供する低水準APIを利用してメソッドを生成する Attribute アトリビュートを表し，アクセサメソッドを所有するクラス Method::Accessorと同じ効果を持つAPIを提供 とりあえずクラス構成だけメモしておく。
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Moose::RoleはJavaのInterfaceなんかじゃない - Pixel Pedals of Tomakomai
Moose::RoleはJavaのInterfaceと似たような物だと思ってたんですが、大きな誤解でした。 モダンPerlの世界へようこそを読んで、Moose::RoleはTraits: Composable Units of Behaviorの概念の実装らしいことがわかったので、この論文を読んでみました。*1。非常に面白い内容でした。P.12 の a) と b) を見るだけでも、この概念の面白さが伝わるんじゃないかと。要は、指定した振る舞い(requires)から新しい振る舞い(provides)を作るものが、Traitsってことです。(ただし、ここで言う振る舞いにはアクセサを含みます。) 誤解していたこと Moose::RoleをTraitsとして見なすとすれば、JavaのInterfaceの性質である以下の2点は誤解です*2。 Moose::Roleは、単なるインタフェース(API)
第4回 Any::Moose：なにがどうでもムースはムース | gihyo.jp
CPANTSは情報の宝庫 Perlを使う最大の利点といわれるCPANですが、CPANは単なるモジュール置き場ではありません。CPANはまたPerlの利用状況を知るうえで不可欠な統計情報を得る場でもあります。そのような統計情報のいくつかは、いわゆるCPAN検索サイトからも確認できますが、より突っ込んだ情報が欲しい場合はCPANTS（CPAN Testing Service）と呼ばれるサイトを確認するのが便利です。 国内ではnipotanこと谷口公一氏が始めた「輝け！全日本最強 CPAN Author 決定選手権」のネタ元として知られていますが、このサイトでは個々の作者やモジュールの品質だけでなく、そのモジュールが実際にどこで使われているかという情報を得ることもできます。 たとえば前回取り上げたロール関連のモジュールの利用状況を調べてみると、古き良きExporterを依存モジュールとして取り上
誰も知らないHTTP::Engineの歴史 〜 第二楽章 - Yappo::タワシ
302 Found の補足というか上俺から目線で語るけど。 最初はyappo wareって事でClass::Component絶頂期だったので Class::Componentで書いていた、がYAPC::Asia 2008 周辺で猛烈なMooseブームが巻き起こり tokuhiromの努力でmoose branchが完成して ------------------------------------------------------------------------ r11460 | yappo | 2008-05-12 18:27:05 +0900 (月, 12 5 2008) | 1 line svk mv branches/moose trunk となった。 その後も粛々と続いていたが、Shibuya.PM CGI祭りとHEcon周辺で自体が代わり Mojoが出たというのとMark
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
初めてのMoose
http://blog.eorzea.asia/2010/02/post_91.html
http://perldoc.perlassociation.org/pod/Moose-Doc-JA/
Stevan Little