5.30.0

名前

perlmod - Perl modules (packages and symbol tables)

perlmod - Perl のモジュール (パッケージとシンボルテーブル)

説明

Is this the document you were after?

There are other documents which might contain the information that you're looking for:

あなたが探している情報を含んでいるかもしれない文書が他にもいくつかあります:

This doc

(この文書)

Perl's packages, namespaces, and some info on classes.

Perl のパッケージ、名前空間、およびクラスに関する少しの情報。

perlnewmod

Tutorial on making a new module.

新しいモジュールを作るためのチュートリアル。

perlmodstyle

Best practices for making a new module.

新しいモジュールを作るときのベストプラクティス。

パッケージ

Unlike Perl 4, in which all the variables were dynamic and shared one global name space, causing maintainability problems, Perl 5 provides two mechanisms for protecting code from having its variables stomped on by other code: lexically scoped variables created with my or state and namespaced global variables, which are exposed via the vars pragma, or the our keyword. Any global variable is considered to be part of a namespace and can be accessed via a "fully qualified form". Conversely, any lexically scoped variable is considered to be part of that lexical-scope, and does not have a "fully qualified form".

全ての変数が動的で一つのグローバルな名前空間であり、 保守性の問題を引き起こしていた Perl 4 と異なり、 Perl 5 は 他のコードが変数を破壊することから守るための二つの機構を 提供します: mystate で作成されるレキシカルスコープ変数と、 vars プラグマや our キーワードを使って公開される名前空間付き グローバル変数です。 全てのグローバル変数は名前空間の一部として扱われ、「完全修飾形式」を使って アクセスできます。 逆に、全てのレキシカルスコープ変数はレキシカルスコープの一部として扱われ、 「完全修飾形式」を持ちません。

In perl namespaces are called "packages" and the package declaration tells the compiler which namespace to prefix to our variables and unqualified dynamic names. This both protects against accidental stomping and provides an interface for deliberately clobbering global dynamic variables declared and used in other scopes or packages, when that is what you want to do.

perl では名前空間は「パッケージ」と呼ばれ、 package 宣言は、どの名前空間を our 変数と完全修飾されていない 動的名に前置するかをコンパイラに知らせます。 これは不慮の破壊を防ぎ、故意にグローバルな動的変数を上書きするための インターフェースを提供して、必要なときに他のスコープやパッケージで 使えるようにします。

The scope of the package declaration is from the declaration itself through the end of the enclosing block, eval, or file, whichever comes first (the same scope as the my(), our(), state(), and local() operators, and also the effect of the experimental "reference aliasing," which may change), or until the next package declaration. Unqualified dynamic identifiers will be in this namespace, except for those few identifiers that, if unqualified, default to the main package instead of the current one as described below. A package statement affects only dynamic global symbols, including subroutine names, and variables you've used local() on, but not lexical variables created with my(), our() or state().

package 宣言のスコープは宣言それ自身から、宣言を囲むブロック、 または eval、ファイルの最初に現れたもの (my(), our(), state(), local() 演算子、あるいは実験的で 変更されるかもしれない「リファレンス別名」のスコープと同じ)、 あるいは次の package 宣言までです。 修飾されていない動的識別子(dynamic identifiers)はその名前空間に 存在するようになりますが、例外として以下に述べるように、いくつかの識別子は 修飾されないと現在のパッケージではなく main パッケージに存在します。 package 文は、サブルーチン名、local() を使った変数を含む 動的大域シンボルにのみ影響し、 my(), our(), state() によって生成されたレキシカル変数には影響 しません

Typically, a package statement is the first declaration in a file included in a program by one of the do, require, or use operators. You can switch into a package in more than one place: package has no effect beyond specifying which symbol table the compiler will use for dynamic symbols for the rest of that block or until the next package statement. You can refer to variables and filehandles in other packages by prefixing the identifier with the package name and a double colon: $Package::Variable. If the package name is null, the main package is assumed. That is, $::sail is equivalent to $main::sail.

典型的には、package 文は do, require, use 演算子のいずれかを 使ってプログラムにインクルードされたファイルの先頭の宣言となります。 二ヶ所以上でパッケージを切り替えることができます: それによって、ブロックの 残りの部分または次の package 文を越えてコンパイラが動的シンボルのために使う シンボルテーブルに影響を与えません。 他のパッケージから識別子にそのパッケージ名とダブルコロンを前置して $Package::Variable のようにすることで、変数やファイルハンドルを 参照することができます。 パッケージ名が空であれば、main が仮定されます。 つまり、$::sail$main::sail は等価になります。

The old package delimiter was a single quote, but double colon is now the preferred delimiter, in part because it's more readable to humans, and in part because it's more readable to emacs macros. It also makes C++ programmers feel like they know what's going on--as opposed to using the single quote as separator, which was there to make Ada programmers feel like they knew what was going on. Because the old-fashioned syntax is still supported for backwards compatibility, if you try to use a string like "This is $owner's house", you'll be accessing $owner::s; that is, the $s variable in package owner, which is probably not what you meant. Use braces to disambiguate, as in "This is ${owner}'s house".

古いパッケージ区切り子はシングルクォートでしたが、現在はダブルコロンを 使うのが推奨されています; なぜなら、この方が人間が読みやすいということと、 emacs マクロで読みやすいからです。 これはまた、C++ プログラマに自分が知っていることのように 思わせるようにもします -- それは以前のシングルクォートが Ada プログラマに 馴染みのものであったことと同じです。 古い構文も互換性のためにまだサポートされているので、 "This is $owner's house" のようにすると、これは $owner::s を アクセスします; つまり、パッケージ owner にある $s という変数をアクセスするのですが、 これはあなたの望んだ動作ではないでしょう。 "This is ${owner}'s house" のようにブレースを使うことによって 曖昧さを除去します。

Packages may themselves contain package separators, as in $OUTER::INNER::var. This implies nothing about the order of name lookups, however. There are no relative packages: all symbols are either local to the current package, or must be fully qualified from the outer package name down. For instance, there is nowhere within package OUTER that $INNER::var refers to $OUTER::INNER::var. INNER refers to a totally separate global package. The custom of treating package names as a hierarchy is very strong, but the language in no way enforces it.

パッケージは $OUTER::INNER::var のように、パッケージセパレータを 含むことができます。 しかしながらこれは、名前の検索に関してなんの仮定も行いません。 相対パッケージはありません: 全てのシンボルはカレントのパッケージに ローカルであるか外側のパッケージから完全に修飾されていなければなりません。 たとえば、パッケージ OUTER から $INNER::var を 参照するには $OUTER::INNER::var とします。 INNER はグローバルパッケージから完全に分離されたものとして 参照します。 パッケージ名を階層として扱うという慣習はとても強いものですが、 言語としてはこれを全く強制しません。

Only identifiers starting with letters (or underscore) are stored in a package's symbol table. All other symbols are kept in package main, including all punctuation variables, like $_. In addition, when unqualified, the identifiers STDIN, STDOUT, STDERR, ARGV, ARGVOUT, ENV, INC, and SIG are forced to be in package main, even when used for other purposes than their built-in ones. If you have a package called m, s, or y, then you can't use the qualified form of an identifier because it would be instead interpreted as a pattern match, a substitution, or a transliteration.

文字(もしくはアンダースコア)で始まる識別子だけがパッケージの シンボルテーブルに格納されます。 その他のシンボルは、$_ のような句読点変数の全てを含め、全て パッケージ main にとどめられます。 それに加え、STDIN, STDOUT, STDERR, ARGV, ARGVOUT, ENV, INC, SIG といった 識別子は、たとえ組み込みでない他の目的のために使っていた場合でも 強制的にパッケージ main に置かれます。 また、ms, y といった名前のパッケージを使っている場合、 修飾形式の識別子を使うことができません; なぜなら、そういったものは パターンマッチ、置換、変換として解釈されてしまうからです。

Variables beginning with underscore used to be forced into package main, but we decided it was more useful for package writers to be able to use leading underscore to indicate private variables and method names. However, variables and functions named with a single _, such as $_ and sub _, are still forced into the package main. See also "The Syntax of Variable Names" in perlvar.

アンダースコアで始まる名前を持った変数は強制的にパッケージ main に 置かれるように使われていましたが、アンダーススコアで始めることを、 パッケージの作者が変数やメソッド名がパッケージにプライベートな ものであることを示すことに使えるようにするのがより便利だろうと 考えてこれを決めました。 しかし、$_ や sub _ のように、単一の _ で始まる名前の変数や関数は 未だに強制的にパッケージ main となります。 "The Syntax of Variable Names" in perlvar も参照してください。

evaled strings are compiled in the package in which the eval() was compiled. (Assignments to $SIG{}, however, assume the signal handler specified is in the main package. Qualify the signal handler name if you wish to have a signal handler in a package.) For an example, examine perldb.pl in the Perl library. It initially switches to the DB package so that the debugger doesn't interfere with variables in the program you are trying to debug. At various points, however, it temporarily switches back to the main package to evaluate various expressions in the context of the main package (or wherever you came from). See perldebug.

eval された文字列は、eval() がコンパイルされたパッケージで コンパイルされます。 (しかし、$SIG{} への代入は、指定したシグナルハンドラが、 パッケージ main にあるものとして扱います。 シグナルハンドラを別のパッケージにおきたい場合には、そのシグナルハンドラ名に パッケージ名を付けてください。) たとえば、Perl ライブラリの perldb.pl を参照してください。 最初に、デバッグしようとするプログラムの変数を、デバッガーが壊さないように、 パッケージ DB に切り替えます。 しかし、多くのポイントで、さまざまな式をパッケージ main (あるいは もともと指定してたパッケージ) で評価するために、一時的に パッケージ main に戻るようにしています。 perldebug を参照してください。

The special symbol __PACKAGE__ contains the current package, but cannot (easily) be used to construct variable names. After my($foo) has hidden package variable $foo, it can still be accessed, without knowing what package you are in, as ${__PACKAGE__.'::foo'}.

特殊シンボル __PACKAGE__ はカレントパッケージを保持していますが、 変数名を構築するために使うことは(簡単には)できません。 my($foo) がパッケージ変数 $foo を隠した後でも、 ${__PACKAGE__.'::foo'} のようにすることで、どのパッケージにいるかという 知識なしにまだアクセス出来ます。

See perlsub for other scoping issues related to my() and local(), and perlref regarding closures.

my() と local() に関連したスコープについては perlsub を、クロージャに ついては perlref 参照してください。

シンボルテーブル

The symbol table for a package happens to be stored in the hash of that name with two colons appended. The main symbol table's name is thus %main::, or %:: for short. Likewise the symbol table for the nested package mentioned earlier is named %OUTER::INNER::.

パッケージのシンボルテーブルは、パッケージ名に二つのコロンを付けた名前の ハッシュに蓄えられます。 つまり、main のシンボルテーブルは %main::、または短く %:: となります。 同様に、先に述べたネストしたパッケージは %OUTER::INNER:: となります。

The value in each entry of the hash is what you are referring to when you use the *name typeglob notation.

ハッシュの個々のエントリの値は、*name 記法を使ったときに参照するものです。

    local *main::foo    = *main::bar;

You can use this to print out all the variables in a package, for instance. The standard but antiquated dumpvar.pl library and the CPAN module Devel::Symdump make use of this.

たとえばこれを、パッケージ内のすべての変数を出力するために使うことができます。 標準ですが古風な dumpvar.pl ライブラリと CPAN モジュール Devel::Symdump で実際に行えます。

The results of creating new symbol table entries directly or modifying any entries that are not already typeglobs are undefined and subject to change between releases of perl.

直接新しいシンボルテーブルエントリを作成したり、既に型グロブになっていない エントリを修正した結果は未定義で、perl のリリースによって 変更されることがあります。

Assignment to a typeglob performs an aliasing operation, i.e.,

型グロブに対する代入は、エイリアス操作を行います; 例えば:

    *dick = *richard;

causes variables, subroutines, formats, and file and directory handles accessible via the identifier richard also to be accessible via the identifier dick. If you want to alias only a particular variable or subroutine, assign a reference instead:

は、richard という識別子でアクセスできる変数、サブルーチン、 ファイルハンドルをdick という識別子でもアクセスできるようにします。 リファレンスを使えば、特定の変数だけとかサブルーチンだけ、と いうように個別に別名を付けることができます:

    *dick = \$richard;

Which makes $richard and $dick the same variable, but leaves @richard and @dick as separate arrays. Tricky, eh?

これは、$richard と $dick を同じ変数にしますが、@richard と @dick は 別の配列のままです。 解りづらいですか?

There is one subtle difference between the following statements:

以下の 2 つの文には、微妙な違いがあります:

    *foo = *bar;
    *foo = \$bar;

*foo = *bar makes the typeglobs themselves synonymous while *foo = \$bar makes the SCALAR portions of two distinct typeglobs refer to the same scalar value. This means that the following code:

*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'!
    }

Would print '1', because $foo holds a reference to the original $bar. The one that was stuffed away by local() and which will be restored when the block ends. Because variables are accessed through the typeglob, you can use *foo = *bar to create an alias which can be localized. (But be aware that this means you can't have a separate @foo and @bar, etc.)

$foo元の $bar へのリファレンスを保持しているので '1' が 表示されます。 これは local() によって追いやられ、ブロックが終わる時に 復元されるものです。 変数は型グロブを通してアクセスされるので、ローカル化できるエイリアスを 作るために *foo = *bar とすることができます。 (しかし、これは @foo@bar などを別々に保持することが できないということに注意してください。)

What makes all of this important is that the Exporter module uses glob aliasing as the import/export mechanism. Whether or not you can properly localize a variable that has been exported from a module depends on how it was exported:

これらのことが重要である理由は、Exporter モジュールはインポート/エクスポート 機構としてグロブによるエイリアスを使うからです。 モジュールからエクスポートされた変数を適切にローカル化できるかどうかは どのようにエクスポートされたかに依存します:

    @EXPORT = qw($FOO); # Usual form, can't be localized
    @EXPORT = qw(*FOO); # Can be localized
    @EXPORT = qw($FOO); # 通常の形式、ローカル化できない
    @EXPORT = qw(*FOO); # ローカル化できる

You can work around the first case by using the fully qualified name ($Package::FOO) where you need a local value, or by overriding it by saying *FOO = *Package::FOO in your script.

1 つ目の場合は、ローカルな値が必要なところで完全修飾名 ($Package::FOO) を使うか、プログラム中で *FOO = *Package::FOO として 上書きすることで回避できます。

The *x = \$y mechanism may be used to pass and return cheap references into or from subroutines if you don't want to copy the whole thing. It only works when assigning to dynamic variables, not lexicals.

*x = \$y 機構は、全てをコピーすることを望まないときに、低コストな リファレンスをサブルーチンに渡したりサブルーチンから返すために 使うことができます。 これは動的変数に対する代入のときにのみ働き、レキシカル変数では 働きません。

    %some_hash = ();                    # can't be my()
    *some_hash = fn( \%another_hash );
    sub fn {
        local *hashsym = shift;
        # now use %hashsym normally, and you
        # will affect the caller's %another_hash
        my %nhash = (); # do what you want
        return \%nhash;
    }
    %some_hash = ();                    # my() にできない
    *some_hash = fn( \%another_hash );
    sub fn {
        local *hashsym = shift;
        # ここで %hashsym を普通に使うと、
        # 呼び出し元の %another_hash に影響を与える
        my %nhash = (); # したいことをする
        return \%nhash;
    }

On return, the reference will overwrite the hash slot in the symbol table specified by the *some_hash typeglob. This is a somewhat tricky way of passing around references cheaply when you don't want to have to remember to dereference variables explicitly.

リターンのときに、このリファレンスは *some_hash 型グロブによって 指定されるシンボルテーブル中にあるハッシュスロットを上書きします。 これは、変数のデリファレンスを明示的に行うことを考えたくないようなときに、 簡単にリファレンスに関するものを渡すトリッキーなやり方です。

Another use of symbol tables is for making "constant" scalars.

シンボルテーブルの別の使い方は、「定数」スカラを生成するためのものです。

    *PI = \3.14159265358979;

Now you cannot alter $PI, which is probably a good thing all in all. This isn't the same as a constant subroutine, which is subject to optimization at compile-time. A constant subroutine is one prototyped to take no arguments and to return a constant expression. See perlsub for details on these. The use constant pragma is a convenient shorthand for these.

この後、$PI を変更することはできません。 これはコンパイル時に最適化が行われる定数サブルーチンとは異なっていて、 最適化は行われません。 定数サブルーチンは引数を取らず定数式を返すようになってプロトタイプが なされているサブルーチンです。 これに関する詳細は perlsub を参照してください。 use constant プラグマは定数サブルーチンを使いやすくします。

You can say *foo{PACKAGE} and *foo{NAME} to find out what name and package the *foo symbol table entry comes from. This may be useful in a subroutine that gets passed typeglobs as arguments:

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

This prints

これは以下のものを出力します:

    You gave me main::foo
    You gave me bar::baz

The *foo{THING} notation can also be used to obtain references to the individual elements of *foo. See perlref.

*foo{THING} 記法は、*foo に属する個々の要素に対するリファレンスを 得るためにも使うことができます。 perlref を参照してください。

Subroutine definitions (and declarations, for that matter) need not necessarily be situated in the package whose symbol table they occupy. You can define a subroutine outside its package by explicitly qualifying the name of the subroutine:

サブルーチン定義(およびついでに言えば宣言) は、それらがいるシンボル テーブルのパッケージ内にいる必要はありません。 サブルーチン名を明示的に修飾することで、パッケージ外のサブルーチンを 定義できます:

    package main;
    sub Some_package::foo { ... }   # &foo defined in Some_package

This is just a shorthand for a typeglob assignment at compile time:

これはコンパイル時の型グロブへの代入の簡単な表現であり:

    BEGIN { *Some_package::foo = sub { ... } }

and is not the same as writing:

以下のように書くのは同じ ではありません:

    {
        package Some_package;
        sub foo { ... }
    }

In the first two versions, the body of the subroutine is lexically in the main package, not in Some_package. So something like this:

最初の 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();

prints:

以下のように表示され:

    in main: $name is 'barney'

rather than:

以下のようにはなりません:

    in Some_package: $name is 'fred'

This also has implications for the use of the SUPER:: qualifier (see perlobj).

SUPER:: 限定子の使用についても影響があります(perlobj を参照して下さい)。

BEGIN, UNITCHECK, CHECK, INIT, END

Five specially named code blocks are executed at the beginning and at the end of a running Perl program. These are the BEGIN, UNITCHECK, CHECK, INIT, and END blocks.

5 つの特殊な名前のついたコードブロックは、Perl プログラムの開始時および 終了時に実行されます。 それは BEGIN, UNITCHECK, CHECK, INIT, END ブロックです。

These code blocks can be prefixed with sub to give the appearance of a subroutine (although this is not considered good style). One should note that these code blocks don't really exist as named subroutines (despite their appearance). The thing that gives this away is the fact that you can have more than one of these code blocks in a program, and they will get all executed at the appropriate moment. So you can't execute any of these code blocks by name.

これらのコードブロックは、サブルーチンのような見た目を与えるために sub を前置できます(しかしこれはよいスタイルとは考えられていません)。 これらのコードブロックは実際には(その見た目に反して)名前付きサブルーチンの ようには存在していないということは注意するべきでしょう。 これで明かされることは、これらのコードブロックはプログラム中に 複数 持つことができ、全て が適切な瞬間に実行されるということです。 従って、これらのコードブロックはどれも名前で実行できません。

A BEGIN code block is executed as soon as possible, that is, the moment it is completely defined, even before the rest of the containing file (or string) is parsed. You may have multiple BEGIN blocks within a file (or eval'ed string); they will execute in order of definition. Because a BEGIN code block executes immediately, it can pull in definitions of subroutines and such from other files in time to be visible to the rest of the compile and run time. Once a BEGIN has run, it is immediately undefined and any code it used is returned to Perl's memory pool.

BEGIN コードブロックは、できるだけ早く、つまり、たとえファイル (または文字列)の残りが解析されていなくても、定義された瞬間に実行されます。 ファイル(または eval された文字列)内に複数の BEGIN ブロックを 置くこともできます; それらは定義された順番に実行されます。 BEGIN ブロックは即座に実行されるので、サブルーチンなどの定義を 他のファイルから読み込んでコンパイル時と実行時の残りの部分から見えるように することができます。 BEGIN が実行されれば、それは即座に未定義になり、使われたコードの 全ては Perl のメモリープールに返されます。

An END code block is executed as late as possible, that is, after perl has finished running the program and just before the interpreter is being exited, even if it is exiting as a result of a die() function. (But not if it's morphing into another program via exec, or being blown out of the water by a signal--you have to trap that yourself (if you can).) You may have multiple END blocks within a file--they will execute in reverse order of definition; that is: last in, first out (LIFO). END blocks are not executed when you run perl with the -c switch, or if compilation fails.

END コードブロックは、できるだけ遅く、つまり、たとえ die() 関数の 結果であっても、perl がプログラムの実行を終えた後、 インタプリタが終了する直前に実行されます。 (しかし、exec を使って別のプログラムになったりとか、シグナルによって 撃沈されるときはそうではありません--(できるものなら) 自分で トラップしなければなりません。) ファイル内に複数の END ブロックを置くこともでき、定義とは 逆の順序で実行されます; つまり、最後に入ったものが最初に出る (LIFO) ということです。 END ブロックは -c オプション付きで起動されたり、コンパイルに 失敗した場合は実行されません。

Note that END code blocks are not executed at the end of a string eval(): if any END code blocks are created in a string eval(), they will be executed just as any other END code block of that package in LIFO order just before the interpreter is being exited.

文字列の eval() の最後では END コードブロックは実行 されない ことに 注意してください: 文字列 eval() の中で END コードブロックが 作成されると、これらはこのパッケージのその他の END コードブロックと 同様に、インタプリタが終了する直前に LIFO 順で実行されます。

Inside an END code block, $? contains the value that the program is going to pass to exit(). You can modify $? to change the exit value of the program. Beware of changing $? by accident (e.g. by running something via system).

END コードブロックの内側では、$? はそのプログラムが exit() に 渡した値が入っています。 プログラムの返す終了コードを変更するために、この変数の値を 変更することができます。 間違って $? を変えてしまうことに注意してください(たとえば system を 使って何かを実行するなど)。

Inside of a END block, the value of ${^GLOBAL_PHASE} will be "END".

END ブロックの内側では、${^GLOBAL_PHASE} の値は "END" です。

UNITCHECK, CHECK and INIT code blocks are useful to catch the transition between the compilation phase and the execution phase of the main program.

UNITCHECK, CHECK, INIT コードブロックは、メインプログラムの コンパイルフェーズと実行フェーズの遷移を捕捉したい場合に便利です。

UNITCHECK blocks are run just after the unit which defined them has been compiled. The main program file and each module it loads are compilation units, as are string evals, run-time code compiled using the (?{ }) construct in a regex, calls to do FILE, require FILE, and code after the -e switch on the command line.

UNITCHECK ブロックは、定義されたコンパイル単位がコンパイルされた直後に 実行されます。 メインプログラムファイルと、それが読み込んだそれぞれのモジュール、 文字列 eval、正規表現内で (?{ }) 構文を使ってコンパイルされた実行時 コード、do FILE への呼び出し、require FILE、コマンドラインの -e オプションの後に書かれているコードがコンパイル単位です。

BEGIN and UNITCHECK blocks are not directly related to the phase of the interpreter. They can be created and executed during any phase.

BEGIN ブロックと UNITCHECK ブロックはインタプリタのフェーズとは 直接の関係はありません。 これらはどのフェーズ中にも作成されて実行されます。

CHECK code blocks are run just after the initial Perl compile phase ends and before the run time begins, in LIFO order. CHECK code blocks are used in the Perl compiler suite to save the compiled state of the program.

CHECK コードブロックは、最初の Perl コンパイルフェーズ終了直後、 実行時が開始する直前に、LIFO 順で実行されます。 CHECK コードブロックは Perl コンパイラスイートがプログラムのコンパイル 状態を保存するために使われます。

Inside of a CHECK block, the value of ${^GLOBAL_PHASE} will be "CHECK".

CHECK ブロックの内側では、${^GLOBAL_PHASE} の値は "CHECK" です。

INIT blocks are run just before the Perl runtime begins execution, in "first in, first out" (FIFO) order.

INIT ブロックは Perl ランタイムが実行を開始する直前に、「先入れ先出し」 (FIFO) 順で実行されます。

Inside of an INIT block, the value of ${^GLOBAL_PHASE} will be "INIT".

INIT ブロックの内側では、${^GLOBAL_PHASE} の値は "INIT" です。

The CHECK and INIT blocks in code compiled by require, string do, or string eval will not be executed if they occur after the end of the main compilation phase; that can be a problem in mod_perl and other persistent environments which use those functions to load code at runtime.

require、文字列 do、文字列 eval でコンパイルされたコード内の CHECKINIT のブロックは、これがメインコンパイルフェーズの 終わりの後に起こると、実行されません; これは mod_perl やその他の実行時に コードを読み込むのにこれらの関数を使う永続環境では問題になることがあります。

When you use the -n and -p switches to Perl, BEGIN and END work just as they do in awk, as a degenerate case. Both BEGIN and CHECK blocks are run when you use the -c switch for a compile-only syntax check, although your main code is not.

Perlに対するスイッチ -n-p を使った場合、BEGINEND は (退化して) awk のそれと同じように、動作します。 -c スイッチによって構文チェックのみ行われる場合、メインのコードが 実行されないのとは対照的に BEGINCHECK の両方のブロックは 実行されます。

The begincheck program makes it all clear, eventually:

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 only _looks_ like it should be confusing.\n";

  __END__

Perl のクラス

There is no special class syntax in Perl, but a package may act as a class if it provides subroutines to act as methods. Such a package may also derive some of its methods from another class (package) by listing the other package name(s) in its global @ISA array (which must be a package global, not a lexical).

Perl 5 にはクラスのための特別な構文はありませんが、メソッドとして 機能するサブルーチンを提供するパッケージはクラスとして機能できます。 そのようなパッケージでは、他のクラス(パッケージ)の名前を配列 @ISA (パッケージグローバルでなければならず、レキシカルにはできません)に 並べることで、そのクラスからメソッドのいくつかを 引き込んでくることができます。

For more on this, see perlootut and perlobj.

詳しくは、perlootutperlobj を参照してください。

Perl のモジュール

A module is just a set of related functions in a library file, i.e., a Perl package with the same name as the file. It is specifically designed to be reusable by other modules or programs. It may do this by providing a mechanism for exporting some of its symbols into the symbol table of any package using it, or it may function as a class definition and make its semantics available implicitly through method calls on the class and its objects, without explicitly exporting anything. Or it can do a little of both.

モジュールは、ライブラリファイル、つまりファイルとして同じ名前を持つ Perl のパッケージにある関係している関数の集合です。 他のモジュールやプログラムから再利用が可能なように特に設計されています。 そのモジュールを使用する任意のパッケージのシンボルテーブルで、 自分のシンボルの一部をエクスポートする機能を用意することでこれを 行なっているとも言え、あるいは、モジュールはクラス定義として 機能することもでき、明示的にシンボルをエクスポートしなくても、 クラスやそのオブジェクトに対するメソッド呼び出しを通して暗黙のうちに 意味が通じるようにすることができます。 両方を少しずつ、同時に使うことも可能です。

For example, to start a traditional, non-OO module called Some::Module, create a file called Some/Module.pm and start with this template:

たとえば Some::Module と呼ばれる伝統的な、非 OO モジュールを始めるには、 以下のテンプレートを使って Some/Module.pm というファイルを作成します:

    package Some::Module;  # assumes Some/Module.pm

    use strict;
    use warnings;

    # Get the import method from Exporter to export functions and
    # variables
    use Exporter 5.57 'import';

    # set the version for version checking
    our $VERSION     = '1.00';

    # Functions and variables which are exported by default
    our @EXPORT      = qw(func1 func2);

    # Functions and variables which can be optionally exported
    our @EXPORT_OK   = qw($Var1 %Hashit func3);

    # exported package globals go here
    our $Var1    = '';
    our %Hashit  = ();

    # non-exported package globals go here
    # (they are still accessible as $Some::Module::stuff)
    our @more    = ();
    our $stuff   = '';

    # file-private lexicals go here, before any functions which use them
    my $priv_var    = '';
    my %secret_hash = ();

    # here's a file-private function as a closure,
    # callable as $priv_func->();
    my $priv_func = sub {
        ...
    };

    # make all your functions, whether exported or not;
    # remember to put something interesting in the {} stubs
    sub func1      { ... }
    sub func2      { ... }

    # this one isn't always exported, but could be called directly
    # as Some::Module::func3()
    sub func3      { ... }

    END { ... }       # module clean-up code here (global destructor)

    1;  # don't forget to return a true value from the file

Then go on to declare and use your variables in functions without any qualifications. See Exporter and the perlmodlib for details on mechanics and style issues in module creation.

こうしてから宣言に移れば、関数の中で変数を修飾しないでも使うことができます。 モジュールの作成に関する仕組みやスタイルに関する詳細は Exporterperlmodlib を参照してください。

Perl modules are included into your program by saying

Perl のモジュールは以下のようにして、プログラムに取り込まれます:

    use Module;

or

または:

    use Module LIST;

This is exactly equivalent to

これは以下のものと全く等価です:

    BEGIN { require 'Module.pm'; 'Module'->import; }

or

または:

    BEGIN { require 'Module.pm'; 'Module'->import( LIST ); }

As a special case

特殊な場合として

    use Module ();

is exactly equivalent to

というのは、以下のものと全く等価です:

    BEGIN { require 'Module.pm'; }

All Perl module files have the extension .pm. The use operator assumes this so you don't have to spell out "Module.pm" in quotes. This also helps to differentiate new modules from old .pl and .ph files. Module names are also capitalized unless they're functioning as pragmas; pragmas are in effect compiler directives, and are sometimes called "pragmatic modules" (or even "pragmata" if you're a classicist).

すべての Perl のモジュールは .pm という拡張子を持っています。 use 演算子はこれをデフォルトにしていますから、クォートで括って、 "Module.pm" と書く必要はありません。 これはまた、新しいモジュールと古い.pl ファイルや .ph ファイルとに 差をつけるのにも役立っています。 モジュール名はプラグマとして働くもの以外は、先頭を大文字にします; プラグマは、コンパイラ指示子であり、「プラグマ的モジュール」 (pragmatic module、あるいは古典学者であれば「プラグマタ」(pagmata)) と 呼ぶ人もあります。

The two statements:

以下の二つの文は:

    require SomeModule;
    require "SomeModule.pm";

differ from each other in two ways. In the first case, any double colons in the module name, such as Some::Module, are translated into your system's directory separator, usually "/". The second case does not, and would have to be specified literally. The other difference is that seeing the first require clues in the compiler that uses of indirect object notation involving "SomeModule", as in $ob = purge SomeModule, are method calls, not function calls. (Yes, this really can make a difference.)

それぞれ異なったものです。 最初のものは Some::Module のような名前にあるダブルコロンはすべて 使っているシステムのディレクトリセパレータに変換されます(通常は "/")。 二番目のものではそうではなく、そういった文字そのものとして扱われます。 そのほかの違いは最初の require ではコンパイラが "SomeModule" に関して間接的オブジェクト記法を使用し、 $ob = purge SomeModule は関数呼び出しではなくメソッド呼び出しと みなします。 (そう、これが決定的な違いですね。)

Because the use statement implies a BEGIN block, the importing of semantics happens as soon as the use statement is compiled, before the rest of the file is compiled. This is how it is able to function as a pragma mechanism, and also how modules are able to declare subroutines that are then visible as list or unary operators for the rest of the current file. This will not work if you use require instead of use. With require you can get into this problem:

use 文は BEGIN ブロックを使っていますから、内容のインポートは、 use 文がコンパイルされるとすぐに、ファイルの残りがコンパイルされる前に 行なわれます。 それによってモジュールがプラグマとして機能することができ、また、 カレントのファイルの残りの部分でリストか単項の演算子として 参照することのできるサブルーチンの宣言ができるのです。 これは、use の代わりに require を使ったのでは、うまく動きません。 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()

In general, use Module () is recommended over require Module, because it determines module availability at compile time, not in the middle of your program's execution. An exception would be if two modules each tried to use each other, and each also called a function from that other module. In that case, it's easy to use require instead.

一般的に言って、use Module () の方が require Module よりも 推奨されます; なぜなら、そうすることによってプログラムの実行時ではなく、 コンパイル時にモジュールのチェックができるからです。 二つのモジュールが互いに use しようとしているときは例外で、 それぞれ他のモジュールから関数を呼び出されます。 この場合、require してしまう方が簡単です。

Perl packages may be nested inside other package names, so we can have package names containing ::. But if we used that package name directly as a filename it would make for unwieldy or impossible filenames on some systems. Therefore, if a module's name is, say, Text::Soundex, then its definition is actually found in the library file Text/Soundex.pm.

Perlのパッケージは、他のパッケージ名の内側にネストすることができるので、 :: を含めたパッケージ名を使うことができます。 しかし、そういったパッケージ名をファイル名として直接使ってしまえば、 一部のシステムでは手に負えなかったり、使うことのできないファイル名と なってしまうでしょう。 したがって、モジュールの名前が Text::Soundex というものであったとすると、 そのライブラリファイルは実際には Text/Soundex.pm として定義されます。

Perl modules always have a .pm file, but there may also be dynamically linked executables (often ending in .so) or autoloaded subroutine definitions (often ending in .al) associated with the module. If so, these will be entirely transparent to the user of the module. It is the responsibility of the .pm file to load (or arrange to autoload) any additional functionality. For example, although the POSIX module happens to do both dynamic loading and autoloading, the user can say just use POSIX to get it all.

Perl のモジュールは .pm ファイルを常に持っていますが、そのモジュールに 対応して動的にリンクされる実行ファイル(しばしば .so で終わります)や、 自動ロードサブルーチン定義(しばしば .al で終わります)が 存在する場合があります。 そういった場合、それらはモジュールのユーザーからも完全に透過的に見えます。 追加機能をロードする (あるいは、自動ロードの準備をする) のは .pm ファイルの責任となります。 例えば、POSIX モジュールは、たまたま、動的ロードも自動ロードも 行ないますが、使う側は、すべてを使えるようにするために use POSIX と書くことができるだけです。

モジュールをスレッドセーフにする

Perl supports a type of threads called interpreter threads (ithreads). These threads can be used explicitly and implicitly.

Perl はインタプリタスレッド (iスレッド) と呼ばれる新しいタイプの スレッドに対応しています。 これらのスレッドは明示的または暗示的に使われます。

Ithreads work by cloning the data tree so that no data is shared between different threads. These threads can be used by using the threads module or by doing fork() on win32 (fake fork() support). When a thread is cloned all Perl data is cloned, however non-Perl data cannot be cloned automatically. Perl after 5.8.0 has support for the CLONE special subroutine. In CLONE you can do whatever you need to do, like for example handle the cloning of non-Perl data, if necessary. CLONE will be called once as a class method for every package that has it defined (or inherits it). It will be called in the context of the new thread, so all modifications are made in the new area. Currently CLONE is called with no parameters other than the invocant package name, but code should not assume that this will remain unchanged, as it is likely that in future extra parameters will be passed in to give more information about the state of cloning.

iスレッドはデータツリーをクローン化することで動作するので、スレッド間では 何のデータも共有されません。 これらのスレッドは、threads を使うか、win32 で fork() を行う (偽の fork() 対応)ことで使われます。 スレッドがクローン化されると、全ての Perl のデータはクローン化されますが、 非 Perl データは自動的にはクローン化できません。 5.8.0 以降の Perl は CLONE 特殊サブルーチンに対応しています。 CLONE 内部では、例えば(もし必要なら)非 perl データのクローン化の 処理といった、必要なことはなんでもできます。 CLONE は定義(または継承)されたパッケージ毎に一度、クラスメソッドとして 呼び出されます。 これは新しいスレッドのコンテキストで呼び出されるので、全ての変更は 新しいスレッドで行われます。 現在のところ CLONE は呼び出し元のパッケージ名以外の引数なしで 呼び出されますが、コード側はこれがずっと続くと仮定するべきではありません; 将来、クローン化の状態についてさらなる情報を与えるために追加の引数が 渡されるかもしれないからです。

If you want to CLONE all objects you will need to keep track of them per package. This is simply done using a hash and Scalar::Util::weaken().

全てのオブジェクトを CLONE したい場合は、それらをパッケージ毎に記録しておく 必要があります。 これは単純にハッシュと Scalar::Util::weaken() を使うことで実現できます。

Perl after 5.8.7 has support for the CLONE_SKIP special subroutine. Like CLONE, CLONE_SKIP is called once per package; however, it is called just before cloning starts, and in the context of the parent thread. If it returns a true value, then no objects of that class will be cloned; or rather, they will be copied as unblessed, undef values. For example: if in the parent there are two references to a single blessed hash, then in the child there will be two references to a single undefined scalar value instead. This provides a simple mechanism for making a module threadsafe; just add sub CLONE_SKIP { 1 } at the top of the class, and DESTROY() will now only be called once per object. Of course, if the child thread needs to make use of the objects, then a more sophisticated approach is needed.

5.8.7 以降の Perl は CLONE_SKIP 特殊サブルーチンに対応しています。 CLONE と同様、CLONE_SKIP はパッケージ毎に 1 回呼び出されます; しかし、これはクローン化が開始する直前に、親スレッドのコンテキストで 呼び出されます。 これが真の値を返すと、このクラスのオブジェクトはクローン化されません; 厳密に言うと、bless されていない undef 値としてコピーされます。 例えば: もし、1 つの bless されたハッシュを示す 2 つのリファレンスが親に ある場合、子では代わりに 1 つの未定義のスカラ値を示す 2 つのリファレンスが あることになります。 これはモジュールをスレッドセーフにする単純な機構を提供します; 単にクラスの先頭に sub CLONE_SKIP { 1 } を追加することで、 DESTROY() はオブジェクト毎に 1 度だけ呼び出されるようになります。 もちろん、もし子スレッドがこのオブジェクトを使う必要があるなら、より 洗練された手法が必要です。

Like CLONE, CLONE_SKIP is currently called with no parameters other than the invocant package name, although that may change. Similarly, to allow for future expansion, the return value should be a single 0 or 1 value.

CLONE と同様に、CLONE_SKIP は現在のところ呼び出し元のパッケージ名 以外の引数なしで呼び出されますが、これは変更されるかもしれません。 同様に、将来の拡張のために、返り値は単一の 01 であるべきです。

SEE ALSO

See perlmodlib for general style issues related to building Perl modules and classes, as well as descriptions of the standard library and CPAN, Exporter for how Perl's standard import/export mechanism works, perlootut and perlobj for in-depth information on creating classes, perlobj for a hard-core reference document on objects, perlsub for an explanation of functions and scoping, and perlxstut and perlguts for more information on writing extension modules.

標準ライブラリや CPAN と同じくらい説明されている Perl のモジュールと クラスに関する一般的なスタイルについては perlmodlib を参照してください; Perl の標準インポート/エクスポート機構がどのように動作しているのかは Exporter を、クラスの作成に関する詳細な情報は perlootutperlobj を、オブジェクトに関するハードコアなリファレンスの ドキュメントは perlobj を、関数とスコーピングの説明はperlsub を、 エクステンションモジュールの記述に関する詳細はperlxstutperlguts を 参照してください。