Catalyst::View::Emailのよみとき

Tracの設定を読むモジュールの後にやっていたこと。

前略のNet::Trac::Configは最終的にTrac::Configという名前で作成。アップするには微妙過ぎると思ってやってない。

Trac::Configを用いて作ったフォームからの送信にて、Emailにての自動返信がほしかった。でも、ArkにはCatalystのView::Emailにあたる存在がない。となるとEmail::SenderとEmail::MIMEを組み合わせて書く必要がある。けど、どうせならArk::View::Emailがあったほうがいいなぁ、と。

Catalyst::View::Emailのリーディング

そこでCatalyst::View::Emailのソースを読んでた。一通りどういうことをやっているかはわかったのだけど、processで腑に落ちない処理があった。

stash_keyにて、$c->stashへと指定した各種情報を$headerに収めていくのだけれど、

my $email  = $c->stash->{$self->{stash_key}};
.
.
my $header  = $email->{header} || [];
push @$header, ('To' => delete $email->{to}) if $email->{to};

pushしてる部分がのみこめない。deleteした時点でundefが$headerに収まるんじゃないのか、と。そこで簡単なサンプルかいて試してみた。

use strict;
use warnings;
use Data::Dumper;

my $sata = [];
printf "\$sata = []\n";
printf "\$sata is []\n";
my $foo->{baz} = "test";
printf "\$foo->{baz} = \"test\"\n";
printf "\$foo->{baz} is %s\n", $foo->{baz};
push @$sata , ('To' => delete $foo->{baz}) if $foo->{baz};
printf "push @\$sata , ('To' => delete \$foo->{baz}) if \$foo->{baz}\n";
printf "\$sata is %s", Dumper $sata;
unless ($foo->{baz}){
    $foo->{baz} = "undefined";
}
printf "\$foo->{baz} is %s\n", $foo->{baz};

結果。

$sata =
$sata is
$foo->{baz} = "test"
$foo->{baz} is test
push @$sata , ('To' => delete $foo->{baz}) if $foo->{baz}
$sata is $VAR1 = [
'To',
'test'
];
$foo->{baz} is undefined

$foo->{baz}が入った後にdeleteが動作してる。いちいちdeleteのためにコード数が増えないようにするための処理ということか。