perlmod - Perl のモジュール (パッケージとシンボルテーブル)
Perlは、他のパッケージの変数によってあるパッケージが壊されるのを
防ぐために、選択的名前空間(alternative namespace)の機構を提供しています。
実際のところ、グローバル変数は Perl にはないのです。
package 文は、コンパイル単位を与えられた名前空間にあるように宣言します。
そのパッケージ宣言のスコープは宣言それ自身から、宣言を囲むブロック、
または eval、ファイルの最初に現れたものまでです
(my() や locla() 演算子のスコープと同じ)。
修飾されていない動的識別子(dynamic identifiers)はその名前空間に
存在するようになりますが、例外として以下に述べるように、いくつかの識別子は
修飾されないと現在のパッケージではなく main パッケージに存在します。
パッケージ文は(local() を使った)動的変数にのみ効果を持ちますが、
my() によって生成されたレキシカル変数には影響 しません。
典型的には、これは do, require, use 演算子を使ってインクルードされた
ファイルの先頭の宣言となります。
二ヶ所以上でパッケージを切り替えることができます。
それによって、ブロックの残りの部分に対してコンパイラが
使うシンボルテーブルに影響を及ぼすにすぎません。
他のパッケージから識別子にそのパッケージ名とダブルコロンを前置して
$Package::Variable のようにすることで、変数やファイルハンドルを
参照することができます。
パッケージ名が空であれば、main が仮定されます。
つまり、$::sail と $main::sail は等価になります。
古いパッケージ区切り子はシングルクォートでしたが、現在はダブルコロンを
使うのが推奨されています。
なぜなら、この方が人間が読みやすいということと、emacs マクロで
読みやすいからです。
これはまた、C++ プログラマに自分が知っていることのように
思わせるようにもします。
それは以前のシングルクォートが Ada プログラマに馴染みのもので
あったことと同じです。
古い構文も互換性のためにまだサポートされているので、
"This is $owner's house" のようにすると、これは $owner::s を
アクセスします;
つまり、パッケージ owner にある $s という変数をアクセスするのですが、
これはあなたの望んだ動作ではないでしょう。
"This is ${owner}'s house" のようにブレースを使うことによって
曖昧さを除去します。
パッケージは $OUTER::INNER::var のように、パッケージセパレータを
含むことができます。
しかしながらこれは、名前の検索に関してなんの仮定も行いません。
相対パッケージはありません: 全てのシンボルはカレントのパッケージに
ローカルであるか外側のパッケージから完全に修飾されていなければなりません。
たとえば、パッケージ OUTER から $INNER::var を
参照するには $OUTER::INNER::var とします。
INNER はグローバルパッケージから完全に分離されたものとして
参照します。
文字(もしくはアンダースコア)で始まる識別子だけがパッケージの
シンボルテーブルに格納されます。
その他のシンボルは、$_ のような句読点変数の全てを含め、全て
パッケージ main にとどめられます。
それに加え、STDIN, STDOUT, STDERR, ARGV, ARGVOUT, ENV, INC, SIG といった
識別子は、たとえ組み込みでない他の目的のために使っていた場合でも
強制的にパッケージ main に置かれます。
また、m、s, y といった名前のパッケージを使っている場合、
修飾形式の識別子を使うことができません。
なぜなら、そういったものはパターンマッチ、置換、変換として
解釈されてしまうからです。
アンダースコアで始まる名前を持った変数は強制的にパッケージ main に
置かれるように使われていましたが、アンダーススコアで始めることを、
パッケージの作者が変数やメソッド名がパッケージにプライベートな
ものであることを示すことに使えるようにするのがより便利だろうと
考えてこれを決めました。
しかし、$_ や sub _ のように、単一の _ で始まる名前の変数や関数は
未だに強制的にパッケージ main となります。
Technical Note on the Syntax of Variable Names in perlvar も
参照してください。
eval された文字列は、eval() がコンパイルされたパッケージで
コンパイルされます。
(しかし、$SIG{} への代入は、指定したシグナルハンドラが、
パッケージ main にあるものとして扱います。
シグナルハンドラを別のパッケージにおきたい場合には、そのシグナルハンドラ名に
パッケージ名を付けてください。)
たとえば、Perl ライブラリの perldb.pl を参照してください。
最初に、デバッグしようとするプログラムの変数を、デバッガーが壊さないように、
パッケージ DB に切り替えます。
しかし、多くのポイントで、さまざまな式をパッケージ main (あるいは
もともと指定してたパッケージ) で評価するために、一時的に
パッケージ main に戻るようにしています。
perldebug を参照してください。
特殊シンボル __PACKAGE__ はカレントパッケージを保持していますが、
変数名を構築するために使うことは(簡単には)できません。
my() と local() に関連したスコープについては perlsub を、クロージャに
ついては perlref 参照してください。
パッケージのシンボルテーブルは、パッケージ名に二つのコロンを付けた名前の
ハッシュに蓄えられます。
つまり、main のシンボルテーブルは %main::、または短く %:: となります。
同様に、先に述べたネストしたパッケージは %OUTER::INNER:: となります。
ハッシュの個々のエントリの値は、*name 記法を使ったときに参照するものです。
local *main::foo = *main::bar;
たとえばこれを、パッケージ内のすべての変数を出力するために使うことができます。 標準ですが古風な dumpvar.pl ライブラリと CPAN モジュール Devel::Symdump で実際に行えます。
型グロブに対する代入は、エイリアス操作を行います; 例えば:
*dick = *richard;
は、richard という識別子でアクセスできる変数、サブルーチン、
ファイルハンドルをdick という識別子でもアクセスできるようにします。
リファレンスを使えば、特定の変数だけとかサブルーチンだけ、と
いうように個別に別名を付けることができます:
*dick = \$richard;
これは、$richard と $dick を同じ変数にしますが、@richard と @dick は 別の配列のままです。 解りづらいですか?
以下の 2 つの文には、微妙な違いがあります:
*foo = *bar;
*foo = \$bar;
*foo = *bar は型グロブそのものを同期させますが、一方
*foo = \$bar 同じスカラ値を示す二つの区別した型グロブの SCALAR 部を
作ります。
これが意味するのは、以下のコードは:
$bar = 1;
*foo = \$bar; # Make $foo an alias for $bar
{
local $bar = 2; # Restrict changes to block
print $foo; # Prints '1'!
}
$foo は 元の $bar -- local() によって追いやられ、ブロックが
終わる時に復元されるもの -- へのリファレンスを保持しているので '1' が
表示されます。
変数は型グロブを通してアクセスされるので、ローカル化できるエイリアスを
作るために *foo = *bar とすることができます。
(しかし、これは @foo と @bar などを別々に保持することが
できないということに注意してください。)
これらのことが重要である理由は、Exporter モジュールはインポート/エクスポート 機構としてグロブによるエイリアスを使うからです。 モジュールからエクスポートされた変数を適切にローカル化できるかどうかは どのようにエクスポートされたかに依存します:
@EXPORT = qw($FOO); # 通常の形式、ローカル化できない
@EXPORT = qw(*FOO); # ローカル化できる
1 つ目の場合は、ローカルな値が必要なところで完全修飾名
($Package::FOO) を使うか、プログラム中で *FOO = *Package::FOO として
上書きすることで回避できます。
*x = \$y 機構は、全てをコピーすることを望まないときに、低コストな
リファレンスをサブルーチンに渡したりサブルーチンから返すために
使うことができます。
これは動的変数に対する代入のときにのみ働き、レキシカル変数では
働きません。
%some_hash = (); # my() にできない
*some_hash = fn( \%another_hash );
sub fn {
local *hashsym = shift;
# ここで %hashsym を普通に使うと、
# 呼び出し元の %another_hash に影響を与える
my %nhash = (); # したいことをする
return \%nhash;
}
リターンのときに、このリファレンスは *some_hash 型グロブによって 指定されるシンボルテーブル中にあるハッシュスロットを上書きします。 これは、変数のデリファレンスを明示的に行うことを考えたくないようなときに、 簡単にリファレンスに関するものを渡すトリッキーなやり方です。
シンボルテーブルの別の使い方は、「定数」スカラを生成するためのものです。
*PI = \3.14159265358979;
この後、$PI を変更することはできません。
これはコンパイル時に最適化が行われる定数サブルーチンとは異なっていて、
最適化は行われません。
定数サブルーチンは引数を取らず定数式を返すようになってプロトタイプが
なされているサブルーチンです。
これに関する詳細は perlsub を参照してください。
use constant プラグマは定数サブルーチンを使いやすくします。
*foo シンボルテーブルにある名前やパッケージを探し出すために、
*foo{PACKAGE} や *foo{NAME} とすることができます。
これは引数として型グロブを渡されるサブルーチン内で便利です。
sub identify_typeglob {
my $glob = shift;
print 'You gave me ', *{$glob}{PACKAGE}, '::', *{$glob}{NAME}, "\n";
}
identify_typeglob *foo;
identify_typeglob *bar::baz;
これは以下のものを出力します:
You gave me main::foo
You gave me bar::baz
*foo{THING} 記法は、*foo に属する個々の要素に対するリファレンスを
得るためにも使うことができます。
perlref を参照してください。
サブルーチン定義(およびついでに言えば宣言) は、それらがいるシンボル テーブルのパッケージ内にいる必要はありません。 サブルーチン名を明示的に修飾することで、パッケージ外のサブルーチンを 定義できます:
package main;
sub Some_package::foo { ... } # &foo defined in Some_package
これはコンパイル時の型グロブへの代入の簡単な表現であり:
BEGIN { *Some_package::foo = sub { ... } }
以下のように書くのは同じ ではありません:
{
package Some_package;
sub foo { ... }
}
最初の 2 つは、サブルーチンの本体は Some_package ではなく main パッケージになります。 それで、以下のようにすると:
package main;
$Some_package::name = "fred";
$main::name = "barney";
sub Some_package::foo {
print "in ", __PACKAGE__, ": \$name is '$name'\n";
}
Some_package::foo();
以下のように表示され:
in main: $name is 'barney'
以下のようにはなりません:
in Some_package: $name is 'fred'
SUPER:: 限定子の使用についても影響があります(perlobj を参照して下さい)。
5 つの特殊な名前のついたコードブロックは、Perl プログラムの開始時および
終了時に実行されます。
それは BEGIN, UNITCHECK, CHECK, INIT, END ブロックです。
これらのコードブロックは、サブルーチンのような見た目を与えるために
sub を前置できます(しかしこれはよいスタイルとは考えられていません)。
これらのコードブロックは実際には(その見た目に反して)名前付きサブルーチンの
ようには存在していないということは注意するべきでしょう。
これで明かされることは、これらのコードブロックはプログラム中に 複数
持つことができ、全て が適切な瞬間に実行されるということです。
従って、これらのコードブロックはどれも名前で実行できません。
BEGIN コードブロックは、できるだけ早く、つまり、たとえファイル
(または文字列)の残りが解析されていなくても、定義された瞬間に実行されます。
ファイル(または eval された文字列)内に複数の BEGIN ブロックを
置くこともでき、それらは定義された順番に実行されます。
BEGIN ブロックは即座に実行されるので、サブルーチンなどの定義を
他のファイルから読み込んでコンパイル時と実行時の残りの部分から見えるように
することができます。
BEGIN が実行されれば、それは即座に未定義になり、使われたコードの
全ては Perl のメモリープールに返されます。
END コードブロックは、できるだけ遅く、つまり、たとえ die() 関数の
結果であっても、perl がプログラムの実行を終えた後、
インタプリタが終了する直前に実行されます
(しかし、exec を使って別のプログラムになったりとか、シグナルによって
撃沈されるときはそうではありません。
(できるものなら) 自分でトラップしなければなりません)。
ファイル内に複数の END ブロックを置くこともでき、定義とは
逆の順序で実行されます。
つまり、最後に入ったものが最初に出る(LIFO) ということです。
END ブロックは -c オプション付きで起動されたり、コンパイルに
失敗した場合は実行されません。
文字列の eval() の最後では END コードブロックは実行 されない ことに
注意してください: 文字列 eval() の中で END コードブロックが
作成されると、これらはこのパッケージのその他の END コードブロックと
同様に、インタプリタが終了する直前に LIFO 順で実行されます。
END コードブロックの内側では、$? はそのプログラムが exit() に
渡した値が入っています。
プログラムの返す終了コードを変更するために、この変数の値を
変更することができます。
間違って $? を変えてしまうことに注意してください(たとえば system を
使って何かを実行するなど)。
UNITCHECK, CHECK, INIT コードブロックは、メインプログラムの
コンパイルフェーズと実行フェーズの遷移を捕捉したい場合に便利です。
UNITCHECK ブロックは、定義されたコンパイル単位がコンパイルされた直後に
実行されます。
メインプログラムファイルと、それが読み込んだそれぞれのモジュール、
文字列 eval、正規表現内で (?{ }) 構文を使ってコンパイルされたコード、
do FILE への呼び出し、require FILE、コマンドラインの
-e オプションの後に書かれているコードがコンパイル単位です。
CHECK コードブロックは、最初の Perl コンパイルフェーズ終了直後、
実行時が開始する直前に、LIFO 順で実行されます。
CHECK コードブロックは Perl コンパイラスイートがプログラムのコンパイル
状態を保存するために使われます。
INIT ブロックは Perl ランタイムが実行を開始する直前に、「先入れ先出し」
(FIFO) 順で実行されます。
CHECK と INIT のコードブロックは、eval() がメインコンパイルフェーズの
終わりの後に起こると、文字列 eval() の内側では実行されません:
これは mod_perl やその他の実行時にコードを読み込むのに eval STRING を
使う永続環境では問題になることがあります。
Perlに対するスイッチ -n と -p を使った場合、BEGIN と END は
(退化して) awk のそれと同じように、動作します。
-c スイッチによって構文チェックのみ行われる場合、メインのコードが
実行されないのとは対照的に BEGIN と CHECK の両方のブロックは
実行されます。
begincheck プログラムは、最終的にこれら全てをはっきりさせます:
#!/usr/bin/perl
# begincheck
print "10. Ordinary code runs at runtime.\n";
END { print "16. So this is the end of the tale.\n" }
INIT { print " 7. INIT blocks run FIFO just before runtime.\n" }
UNITCHECK {
print " 4. And therefore before any CHECK blocks.\n"
}
CHECK { print " 6. So this is the sixth line.\n" }
print "11. It runs in order, of course.\n";
BEGIN { print " 1. BEGIN blocks run FIFO during compilation.\n" }
END { print "15. Read perlmod for the rest of the story.\n" }
CHECK { print " 5. CHECK blocks run LIFO after all compilation.\n" }
INIT { print " 8. Run this again, using Perl's -c switch.\n" }
print "12. This is anti-obfuscated code.\n";
END { print "14. END blocks run LIFO at quitting time.\n" }
BEGIN { print " 2. So this line comes out second.\n" }
UNITCHECK {
print " 3. UNITCHECK blocks run LIFO after each file is compiled.\n"
}
INIT { print " 9. You'll see the difference right away.\n" }
print "13. It merely _looks_ like it should be confusing.\n";
__END__
Perl 5 にはクラスのための特別な構文はありませんが、メソッドとして 機能するサブルーチンを提供するパッケージはクラスとして機能できます。 そのようなパッケージでは、他のクラス(パッケージ)の名前を配列 @ISA (パッケージグローバルでなければならず、レキシカルにはできません)に 並べることで、そのクラスからメソッドのいくつかを 引き込んでくることができます。
詳しくは、perltoot と perlobj を参照してください。
モジュールは、ライブラリファイル、つまりファイルとして同じ名前を持つ Perl のパッケージにある関係している関数の集合です。 他のモジュールやプログラムから再利用が可能なように特に設計されています。 そのモジュールを使用する任意のパッケージのシンボルテーブルで、 自分のシンボルの一部をエクスポートする機能を用意することでこれを 行なっているとも言え、あるいは、モジュールはクラス定義として 機能することもでき、明示的にシンボルをエクスポートしなくても、 クラスやそのオブジェクトに対するメソッド呼び出しを通して暗黙のうちに 意味が通じるようにすることができます。 両方を少しずつ、同時に使うことも可能です。
たとえば Some::Module と呼ばれる伝統的な、非 OO モジュールを始めるには、 以下のテンプレートを使って Some/Module.pm というファイルを作成します:
package Some::Module; # assumes Some/Module.pm
use strict;
use warnings;
BEGIN {
use Exporter ();
our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
# set the version for version checking
$VERSION = 1.00;
# if using RCS/CVS, this may be preferred
$VERSION = sprintf "%d.%03d", q$Revision: 1.1 $ =~ /(\d+)/g;
@ISA = qw(Exporter);
@EXPORT = qw(&func1 &func2 &func4);
%EXPORT_TAGS = ( ); # eg: TAG => [ qw!name1 name2! ],
# your exported package globals go here,
# as well as any optionally exported functions
@EXPORT_OK = qw($Var1 %Hashit &func3);
}
our @EXPORT_OK;
# exported package globals go here
our $Var1;
our %Hashit;
# non-exported package globals go here
our @more;
our $stuff;
# initialize package globals, first exported ones
$Var1 = '';
%Hashit = ();
# then the others (which are still accessible as $Some::Module::stuff)
$stuff = '';
@more = ();
# all file-scoped lexicals must be created before
# the functions below that use them.
# file-private lexicals go here
my $priv_var = '';
my %secret_hash = ();
# here's a file-private function as a closure,
# callable as &$priv_func; it cannot be prototyped.
my $priv_func = sub {
# stuff goes here.
};
# make all your functions, whether exported or not;
# remember to put something interesting in the {} stubs
sub func1 {} # no prototype
sub func2() {} # proto'd void
sub func3($$) {} # proto'd to 2 scalars
# this one isn't exported, but could be called!
sub func4(\%) {} # proto'd to 1 hash ref
END { } # module clean-up code here (global destructor)
## YOUR CODE GOES HERE
1; # don't forget to return a true value from the file
こうしてから宣言に移れば、関数の中で変数を修飾しないでも使うことができます。 モジュールの作成に関する仕組みやスタイルに関する詳細は Exporter と perlmodlib を参照してください。
Perl のモジュールは以下のようにして、プログラムに取り込まれます:
use Module;
または:
use Module LIST;
これは以下のものと全く等価です:
BEGIN { require Module; import Module; }
または:
BEGIN { require Module; import Module LIST; }
特殊な場合として
use Module ();
というのは、以下のものと全く等価です:
BEGIN { require Module; }
すべての Perl のモジュールは .pm という拡張子を持っていて、
use 演算子はこれをデフォルトにしていますから、クォートで括って、
"Module.pm" と書く必要はありません。
これはまた、新しいモジュールと古い.pl ファイルや .ph ファイルとに
差をつけるのにも役立っています。
モジュール名はプラグマとして働くもの以外は、先頭を大文字にします;
プラグマは、コンパイラ指示子であり、「プラグマ的モジュール」
(pragmatic module、あるいは古典学者であれば「プラグマタ」(pagmata)) と
呼ぶ人もあります。
以下の二つの文は:
require SomeModule;
require "SomeModule.pm";
それぞれ異なったものです。
最初のものは Some::Module のような名前にあるダブルコロンはすべて
使っているシステムのディレクトリセパレータに変換されます(通常は "/")。
二番目のものではそうではなく、そういった文字そのものとして扱われます。
そのほかの違いは最初の require ではコンパイラが
"SomeModule" に関して間接的オブジェクト記法を使用し、
$ob = purge SomeModule は関数呼び出しではなくメソッド呼び出しと
みなします(そう、これが決定的な違いですね)。
use 文は BEGIN ブロックを使っていますから、内容のインポートは、
use 文がコンパイルされるとすぐに、ファイルの残りがコンパイルされる前に
行なわれます。
それによってモジュールがプラグマとして機能することができ、また、
カレントのファイルの残りの部分でリストか単項の演算子として
参照することのできるサブルーチンの宣言ができるのです。
これは、use の代わりに require を使ったのでは、うまく動きません:
require Cwd; # make Cwd:: accessible
$here = Cwd::getcwd();
use Cwd; # import names from Cwd::
$here = getcwd();
require Cwd; # make Cwd:: accessible
$here = getcwd(); # oops! no main::getcwd()
一般的に言って、use Module () の方が require Module よりも
推奨されます。
なぜなら、そうすることによってプログラムの実行時ではなく、
コンパイル時にモジュールのチェックができるからです。
二つのモジュールが互いに use しようとしているときは例外で、
それぞれ他のモジュールから関数を呼び出されます。
この場合、require してしまう方が簡単です。
Perlのパッケージは、他のパッケージ名の内側にネストすることができるので、
:: を含めたパッケージ名を使うことができます。
しかし、そういったパッケージ名をファイル名として直接使ってしまえば、
一部のシステムでは手に負えなかったり、使うことのできないファイル名と
なってしまうでしょう。
したがって、モジュールの名前が Text::Soundex というものであったとすると、
そのライブラリファイルは実際には Text/Soundex.pm として定義されます。
Perl のモジュールは .pm ファイルを常に持っていますが、そのモジュールに
対応して動的にリンクされる実行ファイル(しばしば .so で終わります)や、
自動ロードサブルーチン定義(しばしば .al で終わります)が
存在する場合があります。
そういった場合、それらはモジュールのユーザーからも完全に透過的に見えます。
追加機能をロードする (あるいは、自動ロードの準備をする) のは
.pm ファイルの責任となります。
例えば、POSIX モジュールは、たまたま、動的ロードも自動ロードも
行ないますが、使う側は、すべてを使えるようにするために
use POSIX と書くことができるだけです。
5.6.0 から、Perl はインタプリタスレッド (iスレッド) と呼ばれる新しいタイプの スレッドに対応しています。 これらのスレッドは明示的または暗示的に使われます。
iスレッドはデータツリーをクローン化することで動作するので、スレッド間では
何のデータも共有されません。
これらのスレッドは、threads を使うか、win32 で fork() を行う
(偽の fork() 対応)ことで使われます。
スレッドがクローン化されると、全ての Perl のデータはクローン化されますが、
非 Perl データは自動的にはクローン化できません。
5.7.2 以降の Perl は CLONE 特殊サブルーチンに対応しています。
CLONE 内部では、例えば(もし必要なら)非 perl データのクローン化の
処理といった、必要なことはなんでもできます。
CLONE は定義(または継承)されたパッケージ毎に一度、クラスメソッドとして
呼び出されます。
これは新しいスレッドのコンテキストで呼び出されるので、全ての変更は
新しいスレッドで行われます。
現在のところ CLONE は呼び出し元のパッケージ名以外の引数なしで
呼び出されますが、コード側はこれがずっと続くと仮定するべきではありません;
将来、クローン化の状態についてさらなる情報を与えるために追加の引数が
渡されるかもしれないからです。
全てのオブジェクトを CLONE したい場合は、それらをパッケージ毎に記録しておく 必要があります。 これは単純にハッシュと Scalar::Util::weaken() を使うことで実現できます。
5.8.7 以降の Perl は CLONE_SKIP 特殊サブルーチンに対応しています。
CLONE と同様、CLONE_SKIP はパッケージ毎に 1 回呼び出されます;
しかし、これはクローン化が開始する直前に、親スレッドのコンテキストで
呼び出されます。
これが真の値を返すと、このクラスのオブジェクトはクローン化されません;
厳密に言うと、bless されていない undef 値としてコピーされます。
例えば: もし、1 つの bless されたハッシュを示す 2 つのリファレンスが親に
ある場合、子では代わりに 1 つの未定義のスカラ値を示す 2 つのリファレンスが
あることになります。
これはモジュールをスレッドセーフにする単純な機構を提供します;
単にクラスの先頭に sub CLONE_SKIP { 1 } を追加することで、
DESTROY() はオブジェクト毎に 1 度だけ呼び出されるようになります。
もちろん、もし子スレッドがこのオブジェクトを使う必要があるなら、より
洗練された手法が必要です。
CLONE と同様に、CLONE_SKIP は現在のところ呼び出し元のパッケージ名
以外の引数なしで呼び出されますが、これは変更されるかもしれません。
同様に、将来の拡張のために、返り値は単一の 0 か 1 であるべきです。
標準ライブラリや CPAN と同じくらい説明されている Perl のモジュールと クラスに関する一般的なスタイルについては perlmodlib を参照してください。 Perl の標準インポート/エクスポート機構がどのように動作しているのかは Exporter を、クラスの作成に関する詳細なチュートリアルは perltoot と perltooc を、オブジェクトに関するハードコアな リファレンスのドキュメントは perlobj を、関数とスコーピングの説明は perlsub を、エクステンションモジュールの記述に関する詳細は perlxstut と perlguts を参照してください。