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ブロック内の振る舞いを規定する、など）については、稿を改めようと思います。

• 1日24時間という世界の具象クラスではhourが0 <= $_ && $_ < 24の範囲になり、
• 1日30時間という世界の具象クラスではhourが0 <= $_ && $_ < 30の範囲になる

という要件があったときに、事前に（静的に）それぞれ別の型制約を作らずに、最大値を具象クラスから引っこ抜いて型制約で使うということです。これもまたいまいちな実装ですけれども。

追記: テストを薄く書いてバグを除いたほか、見本の時計はロケールにも対応させました。また、cp932でなくUnicodeなコンソールでの字詰めの問題等々を解消しています。上記スクリーンショットも差し替えています。全角半角の「文字幅」の取り扱い方については、（時間があれば）稿を改めて備忘録を起こす予定です。

遂にFF14のベータテスターの募集が始まりました。2010年の正式サービス開始予定を前に、開発も佳境に入っていることとお見受けします。大変期待の持てる作品であり、末永く愛されることを願ってやみません。

さて、応募に際しては必要事項を色々記入することになりますが、いくつか気掛かりな内容がありました。といっても、馬鹿正直に書いた内容が裏目に出たらどうしよう、という心配事でしかないのですが。

物理的資源と人的資源のいずれも、正直に回答しましたが心配の種を播いてもいます。

CPU

まず、CPUです。これはまずい。私が主に使っている環境は少々特殊で、何せラジオボタンの選択項目には使用しているCPUが存在しないという有様です。

サーバーおよびワークステーション用CPUの選択肢がないことは理解出来るのですが、これで「うげっ、こいつはもしかしてPentium IIとかで動かしているのか？」などと思われて落とされないか、戦々恐々です（一部誇張あり）。

OS

主に使っている環境は未だにWindows XP Professional SP3です。モバイルPCではWindows Vistaの荘重な......と言葉を飾っても仕方がないので正直に書きますと「緩慢な」動作に感銘を受けて、Ubuntuを入れたりしています。

一方で、運営側にとって一番ありがたいのは、やはりWindows 7でのテストでしょう。売り止められてサポート期限も切られているWindows XPなどより、サービス開始を起点として一番長い寿命を見込めるWindows 7の方が、テストの

4年前に構築した自作ワークステーションは、Super πなどではまだまだ会社で使っている最新のPCをも蹴散らす成績を残していますけれども、流石にそろそろマザーボードごと交換しようとも考えていますので、その時にはWindows 7を載せようと思います。

ただし、それはあくまで未来の話。現時点では正直にXPと書くしかないので、「何だかんだ言ってもまだまだサービス開始時点ではXPユーザーが一番多いのではないか」という希望的観測を展開することにしました。

貢献時間

テスターとして貢献出来る時間も、少々心配です。平日は21～25時に帰宅するとして、頑張って2時間くらいと計算します。休日は寝溜めをするような非生産的な時間が多いのですが、この生活を見直して4～5時間。しめて「週12時間以上～24時間未満」の枠に収まります。

かつてEverQuestなどで頑張っていた時代（といっても殆どが大学生時代ですが）とはかなり見劣りがするかも知れません。いわゆる廃人などと称されるハードコアプレイヤーの方々と、いわゆるカジュアルプレイヤーの間に位置する、私のようなミドルレンジのプレイヤーが一番多いのではないだろうかと勝手に想像しています。ただ、あくまでテストなので、システム実装的な問題点の確認および報告を行うためには、貢献時間の長さが物を言うことは言うまでもありません。

ということで不安は不安なのですが、設計面やバランス調整など、ミドルレンジのプレイヤーならではの視点で貢献出来る余地があるのではないかとも思いますので、

意向調査

「環境調査」に比べて「意向調査」の色合いが強い項目は、心配の種にならない分、熟慮して回答しました。

訴求点

• 他のプレイヤーとの交流
• 強い敵との戦闘
• 世界観

「上位3つまで」という質問でしたが、順番をさらに付けるとしたら上記の通りになります。伝統的EQプレイヤーの回答ですね。他のプレイヤーとの濃厚な交流を旨とし、それをよすがとしてレイドエンカウンターとの交戦を行うという（PvPではなく）PvE重視で、それらを緻密に織りなされた世界観に抱かれて満喫するという案配です。

FFシリーズに対する情熱

これは大変答え難い質問ですが、私は100点満点中99点としました。

オフライン作品には初代からお世話になって来ました。大学生・社会人になってからは流石に全作品に手を伸ばせている訳ではありませんが、安心して財布の口を開けられるシリーズだと思っています。

オンライン作品については、世間一般では色々な意見が（オフライン作品以上に）あることと思いますが、その運営品質は比較第一級に位置すると考えます。不正行為への厳正な対処は、「当たり前のことを当たり前にする」ことの難しさも相まって、高く評価したい点です。

しかし、いずれも完全というものはありません。そうした「伸びしろ」が満点への差分ということになります。ということで伸びしろは1点分ということになりましたが、今にして思えばもう少し差分を大きく取った方が良かったかも知れません。「テスターに必要なのは太鼓持ちではなくて、真摯な評価者だ！」と突っぱねられる可能性があるからです。

しかし、上記のような採点根拠をstring型で書けない以上、integer型の値でのみ表現する必要があるので、あまり低すぎると「嫌いな人にテストしてもらいたくないね！」と突っぱねられる危険性もあります。

今後の展望

大学生時代と違って、業務に於けるテストの重要性は骨の髄まで染みこみました。テスターに選出いただけた暁には、誠心誠意テストに励む所存です。また、FF14プレイヤー向けウェブシステム「Amikeco」も、ベータテストに後れを取らないよう、開発にさらに発破を掛ける所存です。

といっても、テスターに選出されたことの表明自体がNDAに抵触する可能性もありますので、未来は何とも言えませんが......。

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行目です）。

このモジュールについては稿を改めてご紹介するつもりです。

しかし、クラス定数（のように使うクラスメソッドの戻り値）が単純な値であればともかく、何かの値を元に計算して導出するような代物だった場合、クラス定数（のように......以下略）を使う度に計算されたのではたまりません。

こうした場合には、Memoizeによるメモ化(memoization)が定番の処方箋となります。また、（もはやメモ化の文脈での例としては定番である）フィボナッチ数の計算など、クラス定数として使うものでないメソッドについても、同様にメモ化は強力な最適化方法論です。

Mooseクラスでは単純にMemoizeモジュールを使えば良いのですが、Mooseロールでは少々込み入った手順で使う必要があることが分かったので、備忘録的に書いておきます。

まず、Mooseクラスの例です。素直にmemoize関数を使えます。

{
    package Foo;

    use Moose;
    use Memoize;

    use namespace::clean -except => [qw(meta)];

    memoize qw(bar);

    sub bar {
        warn "bar\n";
        return;
    }

    __PACKAGE__->meta->make_immutable;
}
{
    package main;

    my $foo = Foo->new;
    $foo->bar;
    $foo->bar;
}

Attribute::MemoizeによるMemoizeアトリビュートを使うことも可能です。なお、大変こんがらがり易いのですが、MemoizeアトリビュートというのはMooseのアトリビュートではなくて、Perlの（サブルーチンや変数に付与する）アトリビュートです。

# ...

    use Moose;
    use Attribute::Memoize; # またはuse Attribute::Util qw(Memoize);

    use namespace::clean -except => [qw(meta)];

    sub bar : Memoize {
        warn "bar\n";
        return;
    }

# ...

Mooseロールにあるメソッドのメモ化

ロール消費クラスからメソッドが見えない

ロールでは単純には行きません。以下はCan't locate object method "bar" via package "Foo"という例外を送出します。もう少し正確に定義すると、Foo->meta->has_method('bar')は偽になります。ロール内でメモ化したメソッドは、ロールを消費するクラスからは見えない状態にあるのです。

{
    package FooBase;

    use Moose::Role;
    use Memoize;

    use namespace::clean;

    memoize qw(bar);

    sub bar {
        warn "bar\n";
        return;
    }

    1;
}
{
    package Foo;

    use Moose;

    use namespace::clean -except => [qw(meta)];

    with qw(
        FooBase
    );

    __PACKAGE__->meta->make_immutable;
}
{
    package main;

    my $foo = Foo->new;
    $foo->bar;
    $foo->bar;
}

memoizeにサブルーチンリファレンスを設定する

上記のように嵌ったのでググってみたところ、moose@perl.orgメーリングリストでMemoizing role methodsという、そのものずばりの質疑応答がありました。

有名なMSTことMatt S Troutさんによると、

1. Memoizeのマニュアルには、memoize関数にはメソッド名だけでなくサブルーチンリファレンスも渡せると書いてある
2. memoize関数の戻り値として、メモ化でラッピングしたサブルーチンリファレンスが返るとも書いてある
3. __PACKAGE__->meta->add_method('foo_method' => memoize(sub { ... }));とすれば、メモ化ラッピングサブルーチンに名前を付けて、消費元のクラス(consumer class)にメソッドを生やせる
4. もしくはmemoize('foo_method')の戻り値であるサブルーチンリファレンスをSub::Nameのsubnameに食わせることで、元のメソッド名を乗っ取って、メモ化ラッピングサブルーチン自体が呼ばれるようにすることが出来る

ということです。

subnameの戻り値をさらにグロブリファレンスに入れる理由は、Sub::NameのPODに書いてあります。おまじないだと思って書くことにしましょう。

現在の私の実装

上記を踏まえて、私は現在のところ以下のように実装しています。別の話題（別途記事を設ける予定の「実行時まで遅延させてMooseの型を生成・適用する方法」）の実現可能性調査で使ったGist: #230058から例示します。

# ...

sub _memoize {
    no strict 'refs';
    foreach my $method (qw(
        _numbers            _names
        _names_to_numbers   _numbers_to_names
        to_number           to_name
        maximum_number      maximum_name
        minimum_number      minimum_name
    )) {
        *{$method} = subname __PACKAGE__ . '::' . $method => memoize($method);
    }
}

__PACKAGE__->_memoize;

# ...

メモ化したい対象をforeachのリストに突っ込むだけで、後はいい感じに動いてくれます。

MooseロールにあるメソッドにMemoizeアトリビュートを付与する

これだけでも基本的には満足出来るのですが、メモ化するメソッドの一覧を書くことは、少々面倒です。

希望としては、メソッド側にMemoizeアトリビュートを付与しつつ、各メソッドを列挙することなしに名前空間のマジックに連携させることです。

メソッドにMemoizeアトリビュートを付与すること自体は可能

まず、メソッド側にMemoizeアトリビュートを付与すること自体が出来る、という確認です。

# ...

sub _memoize {
    no strict 'refs';
    foreach my $method_name (qw(
        _numbers            _names
        _names_to_numbers   _numbers_to_names
        to_number           to_name
        maximum_number      maximum_name
        minimum_number      minimum_name
    )) {
        *{$method} = subname __PACKAGE__ . '::' . $method => \&{$method};
    }
}

sub _numbers : Memoize {
    # ...
}

__PACKAGE__->_memoize;

# ...

これで問題なく想定の挙動をしてくれます。しかし、これでは何の解決にもなっていませんね。かえって、各メソッドと_memoizeメソッドの両方でメモ化対象を指定することになるだけ、多重保守の愚を犯してしまいます。DRYでないということです。

メソッドにMemoizeアトリビュートが付与されているかを調査する

メソッド側でMemoizeアトリビュートを付与しさえすれば、後は何もしなくて良い......ということが理想です。そのためには、_memoizeメソッドに於いて全メソッドを見て回って、各々にMemoizeアトリビュートが付いているかどうかを確認し、付いていればsubnameの流れに乗る、ということが出来れば良いわけです。

# ...

use attributes qw();            # 流石にgetという名前はインポートしたくない
use List::MoreUtils qw(any);    # でもanyはいいんです（オレオレ二枚舌基準）

# ...

sub _memoize {
    my $clss = shift;

    foreach my $method ($class->meta->get_all_methods) {
        no strict 'refs';
        *{ $method->name } = subname $class . '::' . $method->name
            => $method->body
                if any { $_ eq 'Memoize' } attributes::get($method->body);
    }

}

# ...

ところが、上記の実装は動きません。ロールにはmetaメソッドがない（ロールはMoose::Objectを持っていない）ためです。

それでは、ロールを消費するクラスのメタオブジェクトを見ようとすると、$consumer_class->metaとなるようにロールを消費するクラスの側で__PACKAGE__->_memoizeする方法などが考えられます。

しかしその案も駄目です。クラス側で_memoizeを呼んだ時には、既にロールはコンパイルされていますので、ロールでMemoizeアトリビュートを付けたメソッドはforeachのリストには入ってきません。

なお、ここまでしれっと書いていますが、そもそもattributes::getは組み込みアトリビュート(locked, methodなど)以外のアトリビュートが帰ってこないようです。従って、実はメソッドがMemoizeアトリビュート付きかどうかを判別する方法が、本日現在の私には分からないというお粗末な事情があります。

サブルーチン定義時に何とかMemoizeする

後からメソッドを洗うことを諦め、メソッドを定義した時点でメモ化しつつsubnameの仕組みに乗っかる案もありました。

# ...

*foo = subname __PACKAGE__ . '::foo' => sub : Memoize {
    # foo本来の実装
};

*bar = subname __PACKAGE__ . '::bar' => sub : Memoize {
    # bar本来の実装
};

# ...

しかし、無名サブルーチンへのアトリビュートの適用は出来ない（と理解している）ため、これも動きません。

ここまで来れば別にAttribute::Memoizeを使わずとも良いわけで、以下のような形でなら定義出来ます。周り巡って出発地点に戻ったような、少々異様なコードになりました。

# ...

{
    no warnings 'once';
    *foo = subname __PACKAGE__ . '::foo' => memoize(sub {
        # foo本来の実装
    });

    *bar = subname __PACKAGE__ . '::bar' => memoize(sub {
        # bar本来の実装
    });
}

# ...

だったら素直に以下のようにした方が直感的かも知れません。いずれにせよ微妙ですが......。

# ...

{
    no warnings 'once';
    *foo = subname __PACKAGE__ . '::foo' => \&foo;
    sub foo : Memoize {
        # foo本来の実装
    }

    *bar = subname __PACKAGE__ . '::bar' => \&bar;
    sub bar : Memoize {
        # bar本来の実装
    }
}

# ...

まとめ ～ 敗北宣言

開き直ってロールを消費するクラス側でメモ化してしまう手もありますが、それでもやはりDRYではありません。Perlのアトリビュート周りも、MooseやClass::MOPの奥深い部分も、私は殆ど理解せずにブラックボックス的に使ってしまっているので、もう少し勉強をしてみたいです。

MSTさんも「Memoizeのマニュアルをちゃんと読まない人達のために、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を撒き散らしていました。反省反省。

以下は補足情報です。

親クラス(Moose::Object)のBUILDARGSを修飾せず、自クラスでBUILDARGSクラスメソッドを定義しても、親クラスのBUILDARGSを呼べば同じ事です。

# ...

sub BUILDARGS {
    my $class = shift;

    my $init_args = $class->SUPER::BUILDARGS(@_);

    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;
}

# ...

親のBUILDARGSを使わない場合

Mooseのコンストラクターは、デフォルトではハッシュリファレンスかハッシュを受け付けます。自分のBUILDARGSクラスメソッド内で、コンストラクター引数がハッシュリファレンスであるかハッシュであるかを判断する処理を書くのは、とても面倒です。

# ...

sub BUILDARGS {
    my $class = shift;

    # @_がハッシュであるかハッシュリファレンスであるかを判別する処理は、
    # Moose::Object::BUILDARGSと同じことなので面倒
    # ...
}

# ...

自分のクラスではコンストラクター引数にハッシュリファレンスのみを受け付ける（ハッシュは受け付けない）と決めてしまえば、例えば以下のようにも書けるでしょう。

# ...

sub BUILDARGS {
    my $class = shift;

    if (@_ == 1 && ref $_[0] eq 'HASH') {
        confess 'Initialization argument must be '
              . 'any one of imperial_era or christian_era'
                if exists $_[0]->{imperial_era} 
                && exists $_[0]->{christian_era};
        return $_[0];   # もしくは$class->SUPER::BUILDARGS($_[0]);
    }
    else {
        return $class->SUPER::BUILDARGS(@_);
    }
}

# ...

ただ、ハッシュを敢えて拒否するような理由がない限りは、費やすべき労力はそれほど変わらないので、素直にMoose::Object::BUILDARGSを呼んだ方が良いと考えます。

余談: ハッシュやハッシュリファレンス以外の引数を使いたい場合

Moose::Manual::Constructionでは、それ以外の場合（例えばスカラー値など）の対処法が書かれています。今回の要件とは違いますが、後輩への説明用に余談として述べておきます。

Personクラスは、米国在住者の背番号（つまりは一意に識別出来る、id）である社会保障番号（ssn : Social Security Number）の文字列を渡すだけでオブジェクトを生成してくれると便利だ、という例です。

# ...

has 'ssn' => (  # 社会保障番号
    is          => 'rw',
);

# ...

around BUILDARGS => sub {
    my $next  = shift;
    my $class = shift;

    if (@_ == 1 && ! ref $_[0]) {
        return $class->$next(ssn => $_[0]);
    }
    else {
        return $class->$next(@_);
    }
};

# ...

昔のバージョンのMoose::Manual::Constructionでは、メソッドモディファイヤーで親を修飾するのではなく、自クラスでBUILDARGSクラスメソッドを実装するように書かれていましたが、これも要は同じ事です。

# ...

sub BUILDARGS {
    my $class = shift;

    if (@_ == 1 && ! ref $_[0]) {
        return {
            ssn => $_[0],
        };
        # 必要に応じて、以下のようにする方が良いかも知れません
        # $class->SUPER::BUILDARGS({ssn => $_[0]});
    }
    else {
        return $class->SUPER::BUILDARGS(@_);
    }
}

# ...

余談: BUILDかBUILDARGSか

BUILDの引数は、コンストラクター引数にハッシュを渡そうがハッシュリファレンスを渡そうが、一律にハッシュリファレンスとなっています。従って、技術的には以下のようにBUILDでバリデーションロジックを設けることも不可能ではありません。

# ...

sub BUILD {
    my $self = shift;

    confess 'Initialization argument must be '
          . 'any one of imperial_era or christian_era'
            if exists $_[0]->{imperial_era} 
            && exists $_[0]->{christian_era};

    return;
}

# ...

しかし、既にオブジェクトを作ってしまった後に、そのオブジェクトの初期化変数を検証するのは、順序が逆転しています。おかしな値を拒絶するのは出来るだけ早い段階の方が良いので、今回の場合はBUILDARGSでフックしています。

勿論、生成されたオブジェクトのアトリビュートを跨いだ検証などは、素直にBUILDを使えば良いです。

この辺りは、初期化時に行いたい処理によって、BUILDARGSにフックするのかBUILDにフックするのかを決めれば良いでしょう。迷ったら、早めに死ぬようにBUILDARGSを選ぶのが無難です（そして、きちんと検証出来ていることをテストで確かめましょう）。

まず、DIパターンやDIコンテナーを使うことの目的は、直接的には、モジュール間（より具体的には、例えばドメインモデルとORMというようなレイヤー間）の結合性を疎にすることです。

「Mooseのアトリビュートへ依存オブジェクトを持たせることでも疎結合に出来る」というdannさんの指摘（DIとは何か 番外編 - DIコンテナを使わずにModelのTestabilityを高める方法）が一つの具体例ですが、元々Perlは（動的言語であるので）イントロスペクション（オブジェクトの中身を実行時に参照すること）のみならず実行時のDI自体はお手の物です。従って、DIがなければ死にそうなくらい大変かというと、必ずしもその通りではありません。

ただ、あまり根を詰めずとも試験容易性（テスタビリティー）の向上という利益が得られるという点で、DIコンテナーのお世話になる費用対効果が大きいと判断しました。私は怠け者なのです。

さらに、DI採用によって将来的に（今回は使用を一旦留保した）新進気鋭のモジュールに切り替え易くするという狙いもあります。これは「新進気鋭のモジュールを活用する実装を一旦断念して、定番のモジュールを活用することにした」という自分自身の負い目に対する代償行動のようですが、これこそが今回DIコンテナーのお世話になることに決めた最大の理由だと自己分析しています。

ということで、何故突然DIコンテナーを実用してみようかと思ったのか、その辺りの事情についての補足でした。前段と後段の内容の結節点となるこの補足がないと、何が何だか分かりませんでしたね。補足があっても寝不足気味なので変なことを書いているおそれがありますが。

この記事の対象読者としては、私と同じMoose初心者の方々を想定しています。

1. そもそもtriggerとは何か
2. 具体的な使いどころ
3. もしtriggerがなければ......
4. lazyした導出先のアトリビュートをclearすべき
5. 具体例の数々（サンプルコードスニペット付き）
6. まとめらしくないまとめ

triggerはMooseのアトリビュートに付加できるオプションの一つです。

Moose::Manual::Attributes（の、石垣さん(charsbarさん)による日本語版）から引用すると、

アトリビュートに値がセットされたときにかならず呼ばれるサブルーチンです。

とあります。

triggerオプションの値はサブルーチンリファレンスを取ります。勿論、匿名サブルーチンリファレンスも設定出来ます。

trigger => \&triggered_method

または

trigger => sub { ... }

などです。

2. 具体的な使いどころ

2.1. ゲッターでは何もせずにセッターの時だけ何かしたい

例えばafterなどのメソッドモディファイヤーの用途として例示されている

• ログ取得
• デバッグ

などの稼働範囲をさらに限定する使い方があります。ゲッターの時は何もせずにセッターの時だけ処理したい場合などに使います。

$thing->foo();としてthingのfooアトリビュートの値を取得する場合には何もせずに、$thing->foo(1);とした場合にwarn "foo attribute is changed";と表示するなどといった場合です。

2.2. アトリビュート間に関数従属の関係がある

しかし、さらによくある例としては、或るfooアトリビュートが他のbarアトリビュートの計算元となる場合でしょう。barアトリビュートがfooアトリビュートによって導出されるということです。語弊を恐れずにRDB的な用語を使うと、barアトリビュートがfooアトリビュートに関数従属する場合であるとも表現できます。

Moose入門研修のスライド（拙訳）には、password（平文パスワード）とhashed_password（ハッシュ化パスワード）という好例が紹介されています。

なお、ハッシュ化パスワードについて補足しておきます。アプリケーションによっては、保安上の観点から、平文パスワードをDBに生で保存せずに、平文パスワードのハッシュ値を保存する設計にすることがあります（認証時には、ユーザーが入力した平文パスワードをハッシュ化し、DBから取り出したハッシュ値と突き合わせます）。ハッシュ化・ハッシュ値についてご存じない方は、暗号化のようなものだと思ってください。

閑話休題。ここで、hashed_passwordはpasswordをハッシュ関数に入れて出て来た値なので、これら二つの値は足並みが揃ったものでなくてはなりません。つまり、passwordが変わったならば、それに対応してhashed_passwordも変わらなければ（passwordを使って再計算しなければ）なりません。

クラスを使う側がそんな作業を行うのは馬鹿げています。アプリケーションでpasswordを変える場所毎にhashed_passwordに値を設定するのは大変ですし、漏れが出るに決まっています。さらに、hashed_passwordに入れる値をpasswordから計算するのは、passwordアトリビュートを持つクラス側がやるべき仕事のはずです。

triggerを使えば、passwordが変更されたタイミングにフックして、hashed_passwordを再計算することを、APIの内側で完結した処理として実装することが出来ます。

3. もしtriggerがなければ......

もしtriggerがないと、例えば下記のような見苦しいコードを都度書かなければなりません。

# ...

has 'foo' => (
    is          => 'rw',
    isa         => 'Any',
);

around foo => sub {
    my ($next, $self, @args) = @_;

    # 引数がなければゲッター
    return $self->$next
        unless scalar @args;

    # セッター
    my $return_value = $self->$next(@args);

    # ここにやりたい処理を書く

    return $return_value;
};

# ...

或いは、以下のように。

# ...

has 'foo' => (
    is          => 'rw',
    isa         => 'Any',
    writer      => 'set_foo',
);

after set_foo => sub {
    my $self = shift;

    # ここにやりたい処理を書く

    return;
};

# ...

これでは宣言的なコーディングが出来ませんよね。「セッターの時にこれをしたい」というプログラマーの意図を端的に表現するには、triggerで言明する方が遙かに分かりやすいです。

# ...

    has 'foo' => (
        is          => 'rw',
        isa         => 'Any',
    );

# ...

    after foo => sub {
        my ($self, @args) = @_;

        # 引数がなければゲッター
        return
            unless scalar @args;

        # セッターなのでここにやりたい処理を書く
    };

# ...

4. lazyした導出先のアトリビュートをclearすべき

この記事の一番大事な点はここです。

ここまでtriggerによってpasswordを使ってhashed_passwordを再計算するなどと書いてきましたが、実はこれはあまり良くない例です。Moose入門研修の内容の通り、lazyとclearerを使うべきでしょう。

理由はlazyと同様で、導出先のアトリビュートでは値を常時抱えている必要がないからです。プログラムの終了まで、もしくは情報源となるアトリビュートに値が再設定されるまで、導出先のアトリビュートはアクセスされないかも知れません。従って、次回アクセスされてから導出しても（遅延設定しても）問題ないのです。

lazyとclearerの組み合わせによって、以下のような素直な実装を簡単に実現出来ます。

package Things;

use Moose;

has 'number' => (   # 数
    is          => 'rw',
    isa         => 'Num',
    trigger     => sub {
        $_[0]->clear_inverse;
    },
);

has 'inverse' => (  # 逆数
    is          => 'ro',
    isa         => 'Num',
    init_arg    => undef,
    lazy_build => 1,
);

sub _build_inverse {
    1 / $_[0]->number;
}

# ...

挙動は以下の通りです。

1. $things->number(42);によって（またはコンストラクター引数でThings->new(number => 42)などとして）導出元アトリビュートであるnumberが設定される
2. numberアトリビュートのtriggerで、$things->clear_inverseが呼ばれる
3. inverseアトリビュートが未設定の状態になる
4. $things->inverseを呼ぶ
5. $things->_build_inverseというビルダーメソッドで逆数を（再）設定する

もし4.が呼ばれなければ、5.の逆数の計算もしないという仕組みです。再設定用として別に編集メソッドも用意する必要もありません（すべてbuilderメソッドが面倒を見てくれます）。

後述しますが、相互に導出し合っているようなアトリビュート群があった場合、さらにひどいことになります。是非clearerを使いましょう。

5. 具体例の数々（サンプルコードスニペット付き）

延々と書き連ねてきましたが、コードを見た方が早いので、いくつか具体例をご紹介しましょう。

5.1. 一方向の単純導出の場合

まずはこれまで使っていたpasswordとhashed_passwordの例です。アトリビュートの関係性をアスキーアートで図示すると、以下のようになります。

password ----> hashed_password

これは上記4.の実装方法と全く同じです。

# ...

use Digest;

# ...

has 'password' => (
    is          => 'rw',
    isa         => 'Str',
    trigger     => sub {
        $_[0]->clear_hashed_password;
    },
);

has 'hashed_password' => (
    is          => 'ro',
    isa         => 'Str',
    init_arg    => undef,
    lazy_build  => 1,
);

sub _build_hashed_password {
    my $digest = Digest->new('SHA-256');
    $digest->add($_[0]->password);

    return $digest->hexdigest;
}

# ...

テストの形をしたサンプルコードは、gist #211069として上げておきました。

今回の説明とは関係ないので上記では書きませんでしたが、いくつか余談を書いておきます。

triggerでclearerを指定する際の注意点

passwordで、直接trigger => \&clear_hashed_passwordと書きたいかも知れませんが、これは出来ません。has 'password'した時点ではhashed_passwordは宣言されていないので、つまりhashed_passwordのlazy_buildによってMooseが生成してくれるclear_hashed_passwordメソッドも存在しないからです（と理解していましたが、エラーではなく警告が出るだけなので、エラーメッセージ通りに解釈するのが正しそうです）。試しに書いてみると、Moose 0.92では以下のような警告が出ます。

You are overwriting a locally defined method (clear_hashed_password) with an accessor

従って、素直に匿名サブルーチンリファレンスを渡すべきです。

勿論、hashed_passwordとpasswordのhasの書き順を逆転させればtrigger => \& clear_hashed_passwordと書くことは出来ますが、

• 導出先アトリビュートが導出元アトリビュートより先に書いてあるとコードの据わりが悪い
• hasの書き順次第で挙動が変わるのは、Mooseに詳しい人でないと分かりにくい（別の人がコードを修正したときに動かなくなる可能性がある）

というような理由により、無精なことはやめておいた方が得策だと思います。後者などは、例えばロールでrequiresしたメソッドがhasで定義するアトリビュート名（アクセッサー）だった場合に、クラス側でhasの後にwithを書かないと駄目だという問題に似ていて、なかなか厄介な問題です。

hashed_passwordの防衛

hashed_passwordでは

• is => 'ro'して読み取り専用にする
• init_arg => undefしてコンストラクターでも設定出来ないようにする

ということをしています。

そもそも、hashed_passwordからpasswordを導出することは出来ません。そもそもハッシュ化とは一方向の変換を前提としているようなものなのですから。従って、hashed_passwordはクラス内部でのみ設定されるようにしておくことが良いでしょう。

より安全にするには、hashed_passwordでclearer => '_clear_hashed_password'などとして、クリア用のメソッドをプライベート然とした名前にすることです。

どこまで制約を掛ける？

hashed_passwordをMyApp::Typesなどで規定したStrAsHexSHA256というような型にするのは考えどころです。（場合によっては）過ぎたるは及ばざるがごとし、になるかも知れません。というのも、上記のようにhashed_passwordの値の設定はAPI内部で完結しているので、API外部から変な値が入ってくることがないからです（カプセル化の原則が守られている限りに於いては、つまり$things->{hashed_password} = 'foo'などとされない限りは）。

誤りを出来るだけ早期に検知するよう、防衛的なプログラミングをするには、制約を是非掛けておきたいところです。値の計算結果が常に正しいことを、アサーションのように書いておくという意味合いです。

しかし値が何度も再設定されうる場合には、Shawn M Mooreさん(sartakさん)が研修で仰っていたことの受け売りですが、パフォーマンス面での問題が出ないかを気にしておいた方が良いでしょう。

どこまでPBPに準拠する？

PBP("Perl Best Practices", 邦訳は『Perlベストプラクティス』)に準拠していない記述がいくつかあります。

まず、パフォーマンスを気にして、triggerやbuilderでは$_[0]という記述を使っています。アプリケーションロジックであれば$self = shift;するのが良いでしょう。また、何も返さないことを明示するreturn;を書いても良いでしょう。しかし、

• そのサブルーチンやメソッドが極めて単純な宣言的な記述である
• 今後それが成長することはほとんど考えられない

というようなオレオレ基準に合致すると考えたため、記述を意図的に端折っています。

trigger => sub {
    $_[0]->clear_hashed_password;
},

という記述と、

trigger => sub {
    my $self = shift;

    $self->clear_hashed_password;

    return;
},

という記述のどちらを選ぶかは、基本的には好みの問題です。

業務では「好み」を忖度出来ませんので、コーディング標準として「1センテンスで記述可能なclearerやbuilderでは、return;を明示せず、my $self = shift;としない」などと決めてしまう手もあります。

ファットカンマの左辺はクォート不要だよね

その通りです。

ですが、派生クラスで継承したアトリビュートでhas '+foo' => ...などとするので、面倒から基底クラス側でもhas 'foo' => ...してしまえという個人的な好みで書いています。

一方、メソッドモディファイヤーによって修飾される対象のメソッド名はクォートしていません。アトリビュートは「物」のようなものと理解してクォートして名前を付ける一方、メソッドは「振る舞い」なので書き下すような感触なので、こちらは付けていません。PBPでも言及されているような慣習的な命名規則によれば、メソッド名にqr{[a-z\d]}i以外の文字を使うことが殆ど全くない上に、アトリビュートでクォートした最大の理由である継承による+付与がないので、こちらは無精しています。

まあ、全部付けるなら付けるで、しゃっきりした方がいいとは思います。

5.2. 複数の導出元がある場合

次に、name（名前）とtitle（敬称）から、メールなどのaddressee（名宛て）を導出する例で考えてみましょう。アトリビュートの関係性をアスキーアートで図示すると、以下のようになります。

name  --+
        +-> addressee
title --+

これは前項の応用編です。addresseeのbuilderはnameとtitleを使うので、nameとtitleそれぞれでclear_addresseeを呼べば良いです。

# ...

has 'name' => (
    is          => 'rw',
    isa         => 'Str',
    trigger     => sub {
        $_[0]->clear_addressee;
    },
);

has 'title' => (
    is          => 'rw',
    isa         => 'Str',
    trigger     => sub {
        $_[0]->clear_addressee;
    },
);

has 'addressee' => (
    is          => 'ro',
    isa         => 'Str',
    lazy_build  => 1,
);

sub _build_addressee {
    $_[0]->title . q{ } . $_[0]->name;
}

# ...

これもgist #211070に保存しています。

_build_addresseeの書きぶり

addresseeが多くのアトリビュートに依拠するならば、_build_addresseeメソッドではsprintfを使った方がコードが綺麗になります。

また、もしtitleがis => Maybe[Str]（つまりis => 'Undef | Str'）だった場合には、

defined $_[0]->title ? $_[0]->title . q{ } . $_[0]->name
                     :                       $_[0]->name;

となるでしょう。

各アトリビュートをより堅くする

例えば業務アプリケーションなどでは以下のようなことをすると思います。

• nameはfirst_name（またはforename）とlast_name（またはfamily_nameやらsurnameやら）に分けるべき
• それらの名前の文字長はDBスキーマのvarchar(XXX)などと足並みを揃えた制約を施す（subtypeを使う）と堅い
• titleはenum(Mr. Ms. Mrs. Miss Dr.)などの選択式にする方が堅い

5.3. 循環的に導出し合っている場合

例えばimperial_era（和暦）とchristian_era（西暦）の関係がこれに当たります。アスキーアートによるアトリビュートの関係性は以下の通りです。

imperial_era <---> christian_era

これは双方のアトリビュートが共に「導出元であり導出先である」と整理出来ますので、以下のように書けます。

package Syouwa;

# ...

our $Delta = 1925;

has 'syouwa_era' => (       # 昭和X年
    is          => 'rw',
    isa         => 'Int',
    lazy_build  => 1,
    trigger     => sub {
        $_[0]->clear_christian_era;
    },
);

has 'christian_era' => (    # 西暦X年
    is          => 'rw',
    isa         => 'Int',
    lazy_build  => 1,
    trigger     => sub {
        $_[0]->clear_syouwa_era;
    },
);

sub build_syouwa_era {
    return $_[0]->syouwa_era + $Delta;
}

# ...

gist #211073には、下記の余談にあるロール版とサブクラス版それぞれを例示するコードを保存しました。

続・triggerでclearerを指定する際の注意点

syouwa_eraでtrigger => \&clear_christian_eraなどと書きたくても駄目なことは、5.1節でご紹介しました。後に書いた西暦の方では（既にclear_showa_eraが存在するので）trigger => \&clear_showa_eraすること自体は可能ですが、記述を統一しておいた方が分かりやすいでしょう。また、そうしておくと、後述のように、トリガーで複数の処理を行いたい場合にも、当該匿名サブルーチン内に処理を書き加えるだけで済みます。

年の制約

より正しくは昭和にwhere { 1 <= $_ && $_ <= 64}という制約を施すべきです。 また、西暦もwhere { 1 <= $_ }すべきでしょう。紀元前は考慮していません。

各アトリビュートのリファレンスを持つ場合

リファレンスによって同一オブジェクト内のアトリビュート間での依存性を表現する場合でも、（異なるオブジェクトのアトリビュート間での循環参照時と同様に）weak_ref => 1することを忘れないようにしてください。

サブクラス化するかロール化する

上記では昭和クラスを想定していましたが、これはいまいちです。なぜなら、明治・大正・平成などに流用が効かないクラスになっているからです。

• 西暦を持つロールと、各元号クラスに分ける
• 元号抽象クラスと、昭和具象クラスに分ける

などの方法で、固定部分と可変部分を峻別しましょう。

ついでに、クラス変数として持っているour $Deltaも、MooseX::ClassAttributeを使ったりロール側で定義するアトリビュートにしたり（その場合はbuild_deltaをrequiresすることになります）と、手を入れておくことも出来ます。

他の例

西暦と皇紀でも大体似たようなものですが、実際には旧暦などを考えなければいけないので気を付けてください。

拙作MooseX::Types::Locale::Language（ISO 639-1の言語コードの制約と型変換）でも、これと同じ状況の例をサンプルコードMooseX-Types-Locale-Language-0.003/examples/complex.plとして付属しています。なお、このモジュールについては別の機会に記事を書くつもりです。

もしclearerを使わないなら......

もしclearerを使わずに関係先のアトリビュートを直接その場で設定しようとするなら、以下のような厄介なことを解決しなければなりません。

• 無限ループを防ぐ仕組みを仕込まなければなりません
• builderと同じ処理を書かなければなりません

無限ループについてですが、これは以下のようにして発生します。

1. $era->imperial_era(1);で元号を設定する
2. 元号のtriggerによって、$self->christian_era( $self->imperial_era + $Delta );などとして西暦を設定する
3. 西暦のtriggerによって、$self->imperial_era( $self->christian_era - $Delta );などとして元号を設定する
4. 2.に戻る

これを防ぐ方法は、例えば以下の通りです。

• セッターメソッドをアトリビュート名とは別の名称にする
• トリガーには匿名でないサブルーチンリファレンスを設定する
• 呼び元のメソッド名を見て、ループを断ち切る

具体的な動きとしては、以下のようになります。

1. $era->_set_imperial_era(1);で元号を設定する
2. 元号のtriggerで$self->_build_by_imperial_eraを呼ぶ
3. 2つ前のメソッドが_set_christian_eraではないので、$self->_set_christian_era( $self->imperial_era + $Delta );として西暦を設定する
4. 西暦のtriggerで$self->_build_by_christian_eraを呼ぶ
5. 2つ前のメソッドが_set_imperial_eraなので、$self->_set_imperial_eraは呼ばずにループを断ち切る

メソッド名を得る実装としては、(caller(2) )[3]で得られる完全修飾メソッド名を使うことになります。

......ああっ、なんて面倒くさいのでしょうか！　とてもやっていられませんが、実はMoose入門研修受講前の私は正にそれをやっていました。私の失敗例もgist #211088として晒しておきましょう。これはひどい。

5.4. さらなる応用例

上記5.3の最後にMooseX::Types::Locale::Languageでの例を掲げました。これは

alpha2 <---> name

という関係性でしたが、MooseX::Types::Locale::Country（ISO 3166-1の国コードの制約と型変換）ではさらに複雑になっています。

   +------> alpha2 <------+
   |           ^          |
   v           |          v
numeric <------+------> name
   ^           |          ^
   |           v          |
   +------> alpha3 <------+

何かの悪い冗談のようですが、これも結局は関係先全てのclearerを呼んで、builderでは関係先のどれかの値を使うようにすればよいのです。

サンプルコードMooseX-Types-Locale-Country-0.000/examples/complex.plの中身を少し転載しておきます。

# ...

    use MooseX::Types::Locale::Country qw(
        Alpha2Country
        Alpha3Country
        NumericCountry
        CountryName
    );
    use Locale::Country;

# ...

    has 'alpha3' => (
        is          => 'rw',
        isa         => Alpha3Country,
        init_arg    => '_alpha3',
        coerce      => 1,
        lazy_build  => 1,
        writer      => '_set_alpha3',
        trigger     => sub {
            $_[0]->clear_alpha2;
            $_[0]->clear_numeric;
            $_[0]->clear_name;
        },
    );

# ...

    sub _build_alpha3 {
          $_[0]->has_alpha2
            ? country_code2code
                ( $_[0]->alpha2,  LOCALE_CODE_ALPHA_2, LOCALE_CODE_ALPHA_3 )
        : $_[0]->has_numeric
            ? country_code2code
                ( $_[0]->numeric, LOCALE_CODE_NUMERIC, LOCALE_CODE_ALPHA_3 )
        :
              country2code
                ( $_[0]->name,    LOCALE_CODE_ALPHA_3 );
    }

# ...

predicateオプション（省略時はlazy_buildオプションの有効時にはhas_ATTRIBUTE）を使っているのが着目点です。

6. まとめらしくないまとめ

triggerとclearerとlazyを組み合わせて使う、それが要点です。

上記5.3.では、triggerとclearerとlazyの組み合わせを知らなかった時期の醜悪なコードを恥を忍んで晒しました。私のようなMoose初心者の方には、これを反面教師としていただけるかも知れません。

Mooseは大変強力です。Mooseを使ってプログラミングする時、「これって気持ち悪い書き方だよね」と思ったら、Moose::ManualやMoose::Cookbookを漁りましょう。きっと洗練された素直な書き方が出来るはずです。

無駄なことを頑張って仕上げるようなガチムチな仕事は避けましょう。大いなる自戒を込めて......。

追記 : 三宅さん(nekoyaさん)のはてブコメントで、triggerは一つしか書けないけど、afterは追加できるという違いは大きいと思うという指摘をいただきました。単に導出先の値をリセットしたいだけならばclearerを使えば済みますが、ロールなどでtriggerされるメソッドの挙動をいじりたい場合には、メソッドモディファイヤーも有用ですね。なお、メソッドモディファイヤーをclearerのメソッドに適用するという合わせ技も出来ますので、夢が拡がります。