NAME

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

DESCRIPTION

Is this the document you were after?

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

この文書: Perl のパッケージ、名前空間、およびクラスに関する少しの情報。
perlnewmod: 新しいモジュールを作るためのチュートリアル。
perlmodstyle: 新しいモジュールを作るときのベストプラクティス。

パッケージ

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

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

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

典型的には、package 文は do, require, use 演算子のいずれかを使ってプログラムにインクルードされたファイルの先頭の宣言となります。二ヶ所以上でパッケージを切り替えることができます: それによって、ブロックの残りの部分または次の package 文を越えてコンパイラが動的シンボルのために使うシンボルテーブルに影響を与えません。他のパッケージから識別子にそのパッケージ名とダブルコロンを前置して $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 となります。 "The Syntax of Variable Names" in perlvar も参照してください。

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

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

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

シンボルテーブル

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

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

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

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

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

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

    *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 へのリファレンスを保持しているので '1' が表示されます。これは local() によって追いやられ、ブロックが終わる時に復元されるものです。変数は型グロブを通してアクセスされるので、ローカル化できるエイリアスを作るために *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 を参照して下さい)。

BEGIN, UNITCHECK, CHECK, INIT, END

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 を使って何かを実行するなど)。

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

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

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

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

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

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

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

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

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

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

  __END__

Perl のクラス

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

詳しくは、perlootut と perlobj を参照してください。

Perl のモジュール

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

たとえば 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

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

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

    use Module;

または:

    use Module LIST;

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

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

または:

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

特殊な場合として

    use Module ();

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

    BEGIN { require 'Module.pm'; }

すべての 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 では以下の問題に行き当たるかもしれません:

    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 と書くことができるだけです。

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

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

iスレッドはデータツリーをクローン化することで動作するので、スレッド間では何のデータも共有されません。これらのスレッドは、threads を使うか、win32 で fork() を行う (偽の fork() 対応)ことで使われます。スレッドがクローン化されると、全ての Perl のデータはクローン化されますが、非 Perl データは自動的にはクローン化できません。 5.8.0 以降の 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 であるべきです。