まったく、時の経つのは早いもので、2009年の年の瀬も押し迫ってきました。夏休みの宿題を9月に入ってから終えるという悪癖があった私のことですから、今年を総括する記事をこんな時刻に書き始めるのも無理からぬ事です。
しかし、新学期の開始日と時間割を突き合わせ、例えば中学校では
という嫌らしい打算で生きて来た私にとっては、むしろこのくらいが普通の生き様とも言えます。
ともあれ、今年2009年を一言で表現するのであれば、ただひたすら「感謝」の一年だった、ということになります。
アセトアルデヒドの勢いで変な物を書いたような気がします。書きかけですけれども。
Games::DateTime - A simple date and time object on any games
たまには脇道に逸れて、ff14.nameおよびff14.asia向けの部品的なモジュールを書くというのも、気分転換に良いかも知れません。何に対しての気分転換かというと、独り身の帰宅路で涙にむせぶ件といったところでしょうか。
上掲のスクリーンショットのような「時計」であればFlashやJavaScriptでもよく見掛けるのですが、「ローカルタイムな地球現在時→仮想世界の現在時」以外に
などが出来る「日付時刻クラス」というのは寡聞にして知らないので、書きました。取り敢えずググって要件を見つけられたのはFF11だけでしたが、起点日時の対称が見付かれば、プレースホルダー的に置くだけ置いたEverQuestなどの実装にも対応出来るかも知れません。
ちなみにスクリーンショットの時計はライブラリー本体ではなくexamplesディレクトリー以下のおまけであるGames::DateTime::Clockです。ff14.nameやff14.asiaでは、最終的にはこれとGames::DateTimeをJavaScriptに移植することになります。
なお、Acme::*以下の名前空間にするかどうかは考え中です。また、テストは酔いが覚めてから書く予定です。などと書いていると肝臓が明日も泣きそうな気がします。
備忘録ですが、MooseX::AbstractFactoryで、ファクトリーメソッドに指定する具象クラス名（の一部）を指定する際にエイリアスを使えるようにしています。ただしHashRefを渡さずにエイリアスクラス名（の一部）を渡す際には、宝箱を開ける為の鍵が当該宝箱の中にあるような状態で、いまいちです。
Mooseの型制約を遅延設定するMooseX::Types::Games::DateTime辺りの小細工（実装クラスに依存してwhereブロック内の振る舞いを規定する、など）については、稿を改めようと思います。
hourが0 <= $_ && $_ < 24の範囲になり、hourが0 <= $_ && $_ < 30の範囲になるという要件があったときに、事前に（静的に）それぞれ別の型制約を作らずに、最大値を具象クラスから引っこ抜いて型制約で使うということです。これもまたいまいちな実装ですけれども。
追記: テストを薄く書いてバグを除いたほか、見本の時計はロケールにも対応させました。また、cp932でなくUnicodeなコンソールでの字詰めの問題等々を解消しています。上記スクリーンショットも差し替えています。全角半角の「文字幅」の取り扱い方については、（時間があれば）稿を改めて備忘録を起こす予定です。
JPerl advent calendar 2009 hacker trackの22日目を執筆させていただきました。
補足情報を簡単に記します。
本サイトはFF14のプレイヤー向けウェブシステムの開発日誌という位置付けですので、FF14の話題にも触れておきます。
遂にFF14のベータテスターの募集が始まりました。2010年の正式サービス開始予定を前に、開発も佳境に入っていることとお見受けします。大変期待の持てる作品であり、末永く愛されることを願ってやみません。
さて、応募に際しては必要事項を色々記入することになりますが、いくつか気掛かりな内容がありました。といっても、馬鹿正直に書いた内容が裏目に出たらどうしよう、という心配事でしかないのですが。
PerlのDIコンテナーであるOrochiは、作者である牧さん(lestrratさん)ご本人がFukuoka.pmのFukuoka Perl Workshop #14のスライドのp.46で「循環依存の解決は実装できてない」と書いていらっしゃいます（参考：平田さんの「Fukuoka Perl Workshop #14に行ってきた」の記事）。
ただし、これは私にとっては特段の制約事項とは感じません。循環依存するようなクラスは、場合にもよりますが、私の場合には大抵クラス設計を誤って陥る泥沼状態であるからです。
とはいえ、クラスが複雑に絡み合う事態は起こり得るので、依存関係には気を付ける必要があります。ただ単に依存がぐるぐる回ってバターにならないようにすることは勿論ですが、依存関係を実際に注入する処理でも気を付ける必要があります。この処理は、dannさんの記事の通り、Java界隈ではwiring（ワイヤリング）という用語が充てられます。
で、そのwiringで気を付けるというのは、具体的には、inject_classの実行順が依存の逆順であってはならない、という点です。当たり前といえば当たり前なのですが、うっかりしていました。
以下はその備忘録と解説です。
Moose/Mouseベースのクラスをテストする際には、本筋とは離れたところで一工夫が必要になることがあります。
例えば以前の記事「Arkアプリケーションの開発者テストでTest::Perl::Criticを使う」では、Test::Perl::Criticに於いて、use Mooseなどでuse strict構文も代替した場合でも、Perl::Critic::Policy::TestingAndDebugging::RequireUseStrictに引っ掛からないようにする方策を例示しました。
これに関連して、メソッド（やファンクション）についてPOD内での言及が網羅されているかを検査するTest::Pod::Coverageで、Moose/Mouse用の一部メソッドの記述を省いてしまいたい場合があります。
具体的なメソッドは、例えば
BUILDARGS()BUILD()DEMOLISH()などのフックポイントです。
私は、PODというものはモジュールの使用者向けの資料であって、内部実装について開発者へ向けて事細かく書くような資料ではないと思っています。場合によりけりですが、基本的にはそうした考えに基づいてPODを書いているつもりです。
そうすると、例えばBUILDARGS()に於いてどのようなパターンで引数の読み替えをするか（例えばIntなスカラー値1つを渡されたら{ epoch => $value }に読み替えるなど）を書くよりも、素直にnew()についての記述を設けた方が良いということになります。
ということで、PODにそれらを書かずに、Pod::Coverage自体の機能を活用することで、「ためにする文書化」（手段の自己目的化）を避けることにしましょう。
all_pod_coverage_ok(
{
also_private => [qw(
BUILDARGS
BUILD
DEMOLISH
)],
},
);
具体例としては、拙作DBICx::Modeler::Generatorの開発者テストであるxt/pod_coverage.tなどを挙げておきます。
なお、Kwaliteeを高くすることなどを目的とした「やせ我慢」について以下で補足しておきます。
Perlでクラス（モジュール）をアンロードする方法として、Class::Unloadを使っています。
Class::Unload->unload('Some::Unneeded::Class');
当初、木本さん(perlcodesampleさん)による「クラスをアンロードする方法」の記事や、そこで言及されているClass::MOP::Class::DESTROY()を参考にして、以下のようなアンロードメソッドも書いてみました。その後、用途に適合するClass::UnloadモジュールがCPANで公開されていることが分かったので、自分の場合はこれを活用させていただこうと思った次第です。
いつの日かClass::Unloadがどうしても使えない場面に立ち会ってしまったら、これを引っ張り出してこようと思います。「だが、私はCPANを使えない！」の全ての処方箋が通用しないという、あまりぞっとしない場面ですが......。
sub _unload_class {
my ($self, $class) = @_;
my @route_to_class = split '::', $class;
# unload class in target library which is dump target of generated classes
# cf. http://d.hatena.ne.jp/perlcodesample/20091101/1246274997
# below codes stolen from Class::MOP::Class::DESTROY()
{
no strict 'refs';
# delete inheritance information from @ISA
@{
$class . '::ISA'
} = ();
# delete class symbol from symbol table
%{
$class . '::'
} = ();
# delete class symbol from upper namespace
delete ${
join '::', @route_to_class[0 .. $#route_to_class - 1], q{}
}{
$route_to_class[-1] . '::'
};
# delete loading information
delete $INC{
(join '/', @route_to_class ) . '.pm'
};
}
return;
}
なお、上記はとあるクラスのメソッドとして実装していますが、$selfは使っていないので、単なるサブルーチンにも出来ます。
ところで、普通に暮らしているだけではクラスをアンロードしたいと思う場合が殆ど全くありません。アンロードしたいという稀少な事例の一つとして、拙作のDBICx::Modeler::Generatorでクラスをリロードするという例を掲げておきます（該当箇所はfcf4b0de...コミットに於けるDBICx::Modeler::Generator::Classの147行目です）。
このモジュールについては稿を改めてご紹介するつもりです。
「perl で trim(完全版)」や「ハッシュ変数に存在しないキーを指定した場合の値は何？」という記事をはてブで拝見しました。Perlでいかにtrimする（前後の空白を取り除く）か、という命題です。しかし、残念なことに、文字コードによってはこれでもまだ完全ではありません。
String::Utilのtrim()が使えます。ということで、モダンにtrimする場合には、以下のように書けます。
use strict;
use warnings;
use utf8;
use String::Util qw(trim);
use Test::More;
# half-width space : 半角スペース
is trim(' foo'), 'foo' => 'half prefix'; # 接頭スペース
is trim('bar '), 'bar' => 'half suffix'; # 接尾スペース
is trim(' baz '), 'baz' => 'half circumfix'; # 接周スペース
# full-width space : 全角スペース
is trim(' foo'), 'foo' => 'full prefix';
is trim('bar '), 'bar' => 'full suffix';
is trim(' baz '), 'baz' => 'full circumfix';
# 両対応
is trim(' foo'), 'foo' => 'both prefix';
is trim('bar '), 'bar' => 'both suffix';
is trim(' baz '), 'baz' => 'both circumfix';
done_testing();
__END__
use utf8しつつUTF-8でテストスクリプトを保存することで、全角スペースも（trim()の中でも使われている正規表現である）\sに該当するようになります。
実際にアプリケーションで使う場合には、Encodeを使って外から来た文字列はdecode()して、外に出す文字列は（必要に応じて）encode()することになります。出力はアプリ作者側でどうにでも出来るので、特に指定する必要がない場合にはUTF-8のままで問題ないでしょう。日本の携帯電話向けには、Shift-JISなどと適宜変えることになります。入力側はEncode::Guess辺りで日和っておくといい感じです。
勿論、モダンな環境を使えない場合や、CPANモジュールが使えない場合（実際は「だが、私はCPANを使えない！」の通り、あまりないです）も多々あるわけで、そうした場合にはトラックバック先に挙げられているような手法を使うのが良いと思います。他にも、「PerlでTrimする！」という記事もあります。
Mooseクラスでのクラス定数は、MooseX::ClassAttributeで定義する方法もありますが、素直なのはクラスメソッドとして実装してしまうことでしょう。これならば、ロールとの相性も良いです。
しかし、クラス定数（のように使うクラスメソッドの戻り値）が単純な値であればともかく、何かの値を元に計算して導出するような代物だった場合、クラス定数（のように......以下略）を使う度に計算されたのではたまりません。
こうした場合には、Memoizeによるメモ化(memoization)が定番の処方箋となります。また、（もはやメモ化の文脈での例としては定番である）フィボナッチ数の計算など、クラス定数として使うものでないメソッドについても、同様にメモ化は強力な最適化方法論です。
Mooseクラスでは単純にMemoizeモジュールを使えば良いのですが、Mooseロールでは少々込み入った手順で使う必要があることが分かったので、備忘録的に書いておきます。
Mooseクラスの生成時に、コンストラクター引数として与えられたハッシュまたはハッシュリファレンスに着目して処理を行いたい場合があります。
例えば、初期化ハッシュキーを跨いだ検証などが挙げられます。triggerの使い方についての記事で説明用に作った、元号と西暦のアトリビュートを持つ昭和クラスで想定してみます。
元号と西暦の両方を指定された場合、その両方のアトリビュートが未指定になります。undefという値が入っているのではなく、has_imperial_eraなどのpredicateメソッドの戻り値が偽であるという意味です。
それでは困るので、コンストラクター引数に指定するのは元号と西暦のどちらか一方のみに制限する......という要件が出て来たこととします。その場合、ハッシュとハッシュリファレンスの両方でキーを見付ける処理をBUILDARGSに書くのではなく、親クラス(最終的な親はMoose::Object)のBUILDARGSを呼ぶようにすると、素直に書けます。
# ...
around BUILDARGS => sub {
my $next = shift;
my $class = shift;
# ここでは@_はハッシュかも知れないしハッシュリファレンスかも知れない
# 親クラス(Moose::Object)のハッシュリファレンス化はBUILDARGSに任せる
my $init_args = $class->$next(@_); # ここではハッシュリファレンス
confess 'Initialization argument must be '
. 'any one of imperial_era or christian_era'
if exists $init_args->{imperial_era}
&& exists $init_args->{christian_era};
return $init_args;
};
# ...
こんなものは常識なのでしょうけれども、意外とこういう初歩的なところの認識が甘くて、今までは（後述するように）ハッシュリファレンスのみを食べるような偏屈APIを撒き散らしていました。反省反省。
以下は補足情報です。
最近のコメント