perlmod - Perl のモジュール (パッケージとシンボルテーブル) (パッケージ) Perl provides a mechanism for alternative namespaces to protect packages from stomping on each other's variables. In fact, there's really no such thing as a global variable in Perl. The package statement declares the compilation unit as being in the given namespace. 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() and local() operators). 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 variables--including those you've used local() on--but not lexical variables created with my(). Typically it would be the first declaration in a file included by the do, require, or use operators. You can switch into a package in more than one place; it merely influences which symbol table is used by the compiler for the rest of that block. 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. Perlは、他のパッケージの変数によってあるパッケージが壊されるのを 防ぐために、選択的名前空間(alternative namespace)の機構を提供しています。 実際のところ、グローバル変数は Perl にはないのです。 package 文は、コンパイル単位を与えられた名前空間にあるように宣言します。 そのパッケージ宣言のスコープは宣言それ自身から、宣言を囲むブロック、 または eval、ファイルの最初に現れたものまでです (my() や locla() 演算子のスコープと同じ)。 修飾されていない動的識別子(dynamic identifiers)はその名前空間に 存在するようになりますが、例外として以下に述べるように、いくつかの識別子は 修飾されないと現在のパッケージではなく main パッケージに存在します。 パッケージ文は(local() を使った)動的変数にのみ効果を持ちますが、 my() によって生成されたレキシカル変数には影響 しません。 典型的には、これは do, require, use 演算子を使ってインクルードされた ファイルの先頭の宣言となります。 二ヶ所以上でパッケージを切り替えることができます。 それによって、ブロックの残りの部分に対してコンパイラが 使うシンボルテーブルに影響を及ぼすにすぎません。 他のパッケージから識別子にそのパッケージ名とダブルコロンを前置して $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. パッケージは $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. variable, punctuation 文字(もしくはアンダースコア)で始まる識別子だけがパッケージの シンボルテーブルに格納されます。 その他のシンボルは、$_ のような句読点変数の全てを含め、全て パッケージ main にとどめられます。 それに加え、STDIN, STDOUT, STDERR, ARGV, ARGVOUT, ENV, INC, SIG といった 識別子は、たとえ組み込みでない他の目的のために使っていた場合でも 強制的にパッケージ main に置かれます。 また、m、s, y といった名前のパッケージを使っている場合、 修飾形式の識別子を使うことができません。 なぜなら、そういったものはパターンマッチ、置換、変換として 解釈されてしまうからです。 variable, punctuation 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 perlvar/"Technical Note on the Syntax of Variable Names". アンダースコアで始まる名前を持った変数は強制的にパッケージ main に 置かれるように使われていましたが、アンダーススコアで始めることを、 パッケージの作者が変数やメソッド名がパッケージにプライベートな ものであることを示すことに使えるようにするのがより便利だろうと 考えてこれを決めました。 しかし、$_ や sub _ のように、単一の _ で始まる名前の変数や関数は 未だに強制的にパッケージ main となります。 perlvar/"Technical Note on the Syntax of Variable Names" も 参照してください。 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. 特殊シンボル __PACKAGE__ はカレントパッケージを保持していますが、 変数名を構築するために使うことは(簡単には)できません。 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. In fact, the following have the same effect, though the first is more efficient because it does the symbol table lookups at compile time: ハッシュの個々のエントリの値は、*name 記法を使ったときに参照するものです。 実際、以下に例示したものは、最初のものがシンボルテーブルを コンパイル時に検索するのでより効率が良いものの、同じ効果を持っています: (Be sure to note the vast difference between the second line above and local $main::foo = $main::bar. The former is accessing the hash %main::, which is the symbol table of package main. The latter is simply assigning scalar $bar in package main to scalar $foo of the same package.) (上記の 2 行目と local $main::foo = $main::The との 大きな 違いに 注意してください。 前者は %main::、つまり main パッケージのシンボルテーブルを アクセスしています。 後者は単に main パッケージのスカラ $bar を同じパッケージの スカラ $foo に代入しています。) 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 で実際に行えます。 Assignment to a typeglob performs an aliasing operation, i.e., 型グロブに対する代入は、エイリアス操作を行います; 例えば: 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 という識別子でもアクセスできるようにします。 リファレンスを使えば、特定の変数だけとかサブルーチンだけ、と いうように個別に別名を付けることができます: 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 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 部を 作ります。 これが意味するのは、以下のコードは: 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 -- local() によって追いやられ、ブロックが 終わる時に復元されるもの -- へのリファレンスを保持しているので '1' が 表示されます。 変数は型グロブを通してアクセスされるので、ローカル化できるエイリアスを 作るために *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 モジュールはインポート/エクスポート 機構としてグロブによるエイリアスを使うからです。 モジュールからエクスポートされた変数を適切にローカル化できるかどうかは どのようにエクスポートされたかに依存します: 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 機構は、全てをコピーすることを望まないときに、低コストな リファレンスをサブルーチンに渡したりサブルーチンから返すために 使うことができます。 これは動的変数に対する代入のときにのみ働き、レキシカル変数では 働きません。 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. constant scalar, constant シンボルテーブルの別の使い方は、「定数」スカラを生成するためのものです。 constant scalar, constant 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} とすることができます。 これは引数として型グロブを渡されるサブルーチン内で便利です。 This prints これは以下のものを出力します: 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: サブルーチン定義(およびついでに言えば宣言) は、それらがいるシンボル テーブルのパッケージ内にいる必要はありません。 サブルーチン名を明示的に修飾することで、パッケージ外のサブルーチンを 定義できます: This is just a shorthand for a typeglob assignment at compile time: これはコンパイル時の型グロブへの代入の簡単な表現であり: and is not the same as writing: 以下のように書くのは同じ ではありません: 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 パッケージになります。 それで、以下のようにすると: prints: 以下のように表示され: rather than: 以下のようにはなりません: This also has implications for the use of the SUPER:: qualifier (see perlobj). SUPER:: 限定子の使用についても影響があります(perlobj を参照して下さい)。 Four specially named code blocks are executed at the beginning and at the end of a running Perl program. These are the BEGIN, CHECK, INIT, and END blocks. 4 つの特殊な名前のついたコードブロックは、Perl プログラムの開始時および 終了時に実行されます。 それは BEGIN, 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 のメモリープールに返されます。 It should be noted that BEGIN code blocks are executed inside string eval()'s. The CHECK and INIT code blocks are not executed inside a string eval, which e.g. can be a problem in a mod_perl environment. BEGIN コードブロックは文字列の eval() の内側で 実行される ことに 注意した方が良いでしょう。 CHECK と INIT コードブロックは文字列 eval の内側で 実行されません; これは mod_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 を 使って何かを実行するなど)。 CHECK and INIT code blocks are useful to catch the transition between the compilation phase and the execution phase of the main program. CHECK と INIT コードブロックは、メインプログラムの コンパイルフェーズと実行フェーズの遷移を捕捉したい場合に便利です。 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 コンパイラスイートがプログラムのコンパイル 状態を保存するために使われます。 INIT blocks are run just before the Perl runtime begins execution, in "first in, first out" (FIFO) order. For example, the code generators documented in perlcc make use of INIT blocks to initialize and resolve pointers to XSUBs. INIT ブロックは Perl ランタイムが実行を開始する直前に、「先入れ先出し」 (FIFO) 順で実行されます。 例えば、perlcc で文書化されているコードジェネレータは INIT ブロックを 初期化と、XSUB へのポインタの解決に使います。 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 を使った場合、BEGIN と END は (退化して) awk のそれと同じように、動作します。 -c スイッチによって構文チェックのみ行われる場合、メインのコードが 実行されないのとは対照的に BEGIN と CHECK の両方のブロックは 実行されます。 The begincheck program makes it all clear, eventually: begincheck プログラムは、最終的にこれら全てをはっきりさせます: (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 perltoot and perlobj. 詳しくは、perltoot と perlobj を参照してください。 (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 というファイルを作成します: [ qw!name1 name2! ], ]]> 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. こうしてから宣言に移れば、関数の中で変数を修飾しないでも使うことができます。 モジュールの作成に関する仕組みやスタイルに関する詳細は Exporter と perlmodlib を参照してください。 Perl modules are included into your program by saying Perl のモジュールは以下のようにして、プログラムに取り込まれます: or または: This is exactly equivalent to これは以下のものと全く等価です: or または: As a special case 特殊な場合として is exactly equivalent to というのは、以下のものと全く等価です: 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: 以下の二つの文は: 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 を使ったのでは、うまく動きません: 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 と書くことができるだけです。 (モジュールをスレッドセーフにする) Since 5.6.0, Perl has had support for a new type of threads called interpreter threads (ithreads). These threads can be used explicitly and implicitly. 5.6.0 から、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.7.2 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.7.2 以降の 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. 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 be 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 値としてコピーされます。 これはモジュールをスレッドセーフにする単純な機構を提供します; 単にクラスの先頭に 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 は現在のところ呼び出し元のパッケージ名 以外の引数なしで呼び出されますが、これは変更されるかもしれません。 同様に、将来の拡張のために、返り値は単一の 0 か 1 であるべきです。 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, perltoot and perltooc for an in-depth tutorial 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 を、クラスの作成に関する詳細なチュートリアルは perltoot と perltooc を、オブジェクトに関するハードコアな リファレンスのドキュメントは perlobj を、関数とスコーピングの説明は perlsub を、エクステンションモジュールの記述に関する詳細は perlxstut と perlguts を参照してください。 Created: KIMURA Koichi Updated: Kentaro Shirakata <argrath@ub32.org> (5.8.8-)