Perl 環境は、以前に遭遇した言語とはかなり異なるため、警戒しています。
強力な型付けと関数プロトタイプを信じる人々はここで意見を異にするでしょうが、そのような制限が役立つことはめったにないと思います。Cは、関数に間違った数のパラメーターを頻繁に渡して有用であることに気付いたことがありますか?
@_
最近の Perl では、 の内容を字句スカラー変数のリストにコピーするのが最も一般的です。
sub mysub {
my ($p1, $p2) = @_;
... etc.
}
そうすれば、渡されたすべてのパラメーターは@_
($_[0]
など$_[1]
) の要素として使用できるようになりますが、期待されるものは名前が付けられて and に表示され$p1
ます$p2
(ただし、これらの名前は適切に選択する必要があることを理解していただければ幸いです)。
サブルーチンがメソッドである特定のケースでは、最初のパラメーターは特別です。他の言語ではself
またはthis
ですが、Perl では単純に の最初のパラメーターで@_
あり、好きなように呼ぶことができます。そのような状況では、あなたは見るでしょう
sub method {
my $self = shift;
my ($p1, $p2) = @_;
... etc.
}
コンテキストオブジェクト(またはクラスメソッドの場合はクラスの名前)が$self
(慣例で想定される名前)に抽出され、残りのパラメーターは@_
直接アクセスされるか、より通常はローカルにコピーされるように残りますなど$p1
のスカラー変数$p2
ほとんどの場合、型チェックも行われないため、任意のスカラーをサブルーチン パラメーターとして渡すことができます。use strict
とがコンテキスト内にある限りuse warnings
、サブルーチンが 1 つの形式のスカラーに対して実行できる操作は、通常、別の形式では正しくないという単純な理由から、これでさえデバッグするのは一般に簡単です。
元々はオブジェクト指向の Perl に関してはカプセル化に関するものでしたが、Larry Wall からのこの引用は非常に関連性があります。
Perl は強制されたプライバシーに夢中になりません。散弾銃を持っているからではなく、招待されていないので、リビングルームから離れた方がいいでしょう。
C は、実行時ではなくコンパイル時に障害のあるプログラムを失敗させることができれば、効率が大幅に向上する時代に設計および実装されました。現在は状況が変わっていますが、クライアント側の JavaScript で同様の状況が発生しており、インターネットからデータを取得する前にコードが間違っていることを知っておくと便利です。悲しいことに、JavaScript パラメーターのチェックは本来より緩くなっています。
アップデート
教育目的での Perl の有用性を疑う人のために、私は、Perl のメカニズムが非常に単純で直接的であるため、そのような目的に理想的であることを提案します。
Perl サブルーチンを呼び出すと、呼び出し内のすべてのパラメーターが.ini ファイルにエイリアスされ@_
ます。それらを直接使用して実際のパラメーターに影響を与えるか、コピーして外部アクションを防ぐことができます
Perl サブルーチンをメソッドとして呼び出すと、呼び出し元のオブジェクトまたはクラスが最初のパラメーターとして提供されます。繰り返しますが、サブルーチン (メソッド) は好きなことを行うことができます@_