タグ

modernperlに関するbeth321のブックマーク (6)

  • 第8回 Reaction:CatalystをもっとDRYに | gihyo.jp

    アプリケーションの枠組みを越えた再利用 前回は、Catalyst 5.7で登場したチェーンドアクションを利用して適切なベースコントローラをつくれば、CRUDのような定型処理は再利用できるようになる、という話をしました。これはコンテントマネジメントシステム(CMS)のように同じようなインタフェースを持つ画面が多いシステムをつくるときには特に効果的なのですが、その再利用を、ひとつのアプリケーション内だけで完結させてしまうのはもったいない話。自社でつくるアプリケーションにはどんどん使い回していきたいものですし、コピー&ペーストを避けるためには、なんらかの名前空間上にその共通コードをまとめていく必要があります。 もちろんそのコードが小さく、十分に一般化できるものなら、Catalyst、あるいはCatalystXという名前空間に入れてもかまいませんが、コントローラの部品だけでなく、モデルやビューまで

    第8回 Reaction:CatalystをもっとDRYに | gihyo.jp
  • 第35回 DBI:生のSQLが散らばると言う前に | gihyo.jp

    Perldbm いまでは省みられることも少なくなりましたが、Perlには1989年にリリースされたバージョン3.0以降、dbmと呼ばれるシンプルなデータベースにアクセスする機構が標準で組み込まれています。このdbmは、いわゆるリレーショナルデータベースとは違ってキーと値の組み合わせをディスクに保存できるだけのものですが、ハッシュ(当時はまだ連想配列と呼んでいました)と結びつけることでタブ区切りファイルなどを読んでいくより高速に検索ができたため、ユーザ環境に永続的なデータを保存する手段のひとつとして重宝されていました。Perl 3/4の時代にはdbmopenというコマンドが使われていましたが、この機構はPerl 5になって一新され、いまではより汎用的なtieというコマンドを使うことになっています。この仲間としては古くからあるBerkeley DBやGDBMなどのほか、最近では平林幹雄氏のT

    第35回 DBI:生のSQLが散らばると言う前に | gihyo.jp
  • 第12回 POE:「Perl萌え~」の略ではなく | gihyo.jp

    あだ名の多さは人気の証明? POEという名前にはあきれるほど多くの寓意がこじつけられています。もともとはPerl Object Environment「Perlのオブジェクト環境」の頭文字を並べたものですが、POEの公式サイトを見てみると、Edgar Allan POE「エドガー・アラン・ポー」に始まり(そう、POEは「ポエ」ではなく「ポー」(⁠ないし「ポゥ⁠」⁠)と読みます⁠)⁠、Parallel Object Executor「オブジェクトの並列処理機⁠」⁠、Pathetically Over-Engineered「涙がちょちょ切れるほど作り込みすぎた⁠」⁠、Perl Obfuscation Engine「Perl難読化エンジン⁠」⁠、Perl Objects for Events「イベント用Perlオブジェクト⁠」⁠、Persistent Object Environment「永続オ

    第12回 POE:「Perl萌え~」の略ではなく | 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
  • 第27回 Test::Most:Test::Moreでは物足りなくなってきたら | gihyo.jp

    Test Anything Protocol Perlは非常にテストを重視している言語です。連載第14回ではPerl体のテスト数がどのように推移してきたかを、また連載第24回ではCPANモジュールの品質保証に大きな役割を果たしてきたCPANTSについて簡単に紹介しましたが、Perlとテストのつながりはそれだけではありません。CPANにはTestを名前に含むディストリビューションが500以上もあがっていますし(これは全ディストリビューション数の約2.5%にあたります⁠)⁠、Perlで標準的に使われているテスト形式はTest Anything Protocol (TAP)という名前を得て多くの言語に移植され、2008年からはIETFの標準化を目指した活動も始まっています――というと何やらすごいプロトコルのように聞こえるかもしれませんが、Test Anything Protocolというのは要

    第27回 Test::Most:Test::Moreでは物足りなくなってきたら | gihyo.jp
  • 第2回 mro:次のメソッドはどこ? | gihyo.jp

    モダンなクラス/オブジェクトのあり方は? Perlではそもそもオブジェクトという考え方自体が、Perl 5(Perl 7歳)ではじめて登場した、後付けのものでした。また、その実装も非常におおらかなものだったため、より「格的な」オブジェクト機構を備えた言語のユーザからはしばしば批判されてきました。 ただし、転んでもただでは起きないのがPerlハッカーたちのよいところ。そのような批判を糧に、「⁠モダンPerl」の世界でもっとも激しく、多様に進化してきたのがこの分野です。 今回はそのようなクラス/オブジェクトの進化の一例として、クラスの継承とメソッドの解決順序にまつわる話題をまとめていきます。 継承によるクラスの拡張 伝統的なbaseプラグマを使ってクラスを拡張する場合、継承元と継承先に同名のメソッドがあれば継承先のメソッドだけが優先的に実行されます。 use strict; use warn

    第2回 mro:次のメソッドはどこ? | gihyo.jp
  • 1