答え。

Perlには、public/private/protectedのような伝統的なアクセス修飾子のシステムはありません。関数やデータへのアクセス管理は、合意や変数のスコープを通じて行われます。

モジュール内の変数のアクセスを制限するために、myキーワード（ファイルまたはブロック内のレキシカルスコープ）を使用し、シンボルをエクスポートします（Exporterや独自のメカニズムを通じて）。
外部にエクスポートされないサブルーチン（@EXPORT、@EXPORT_OK）は、デフォルトでモジュール内に「内部的」に留まりますが、必要に応じてパッケージのプレフィックスを使用して明示的に呼び出すことができます。
内部関数や変数は、プライバシーの合意を示すためにアンダースコア（_internal_sub）で始めることが一般的です。

例：

package MyLib;
use Exporter 'import';
our @EXPORT_OK = qw(public_func);

my $secret = 123; # 外部からはアクセスできません

sub public_func {
    _internal_func();
}

sub _internal_func {
    print "これは内部です！
";
}

1;

トリックのある質問。

Perlモジュールのプライベート関数を外部からの呼び出しから保護するための対策は何ですか？直接呼び出すことはできないのですか？

答え： 実際には、パッケージの任意のサブルーチンを完全な名前で明示的に呼び出すことができます：MyLib::_internal_func()。Perlはこの呼び出しを技術的に制限していません — 保護は合意のレベルにあります。

テーマの微妙な点を知らなかったことによる実際のエラーの例。

逸話

開発者がモジュールから多くの関数をエクスポートしすぎて、@EXPORT_OKによる制限を忘れました。その結果、ユーザーは偶然内部関数にアクセスでき、名前の衝突やAPIの誤用が発生しました。

逸話

大規模プロジェクトで、2つのチームがプライベートであると思っていた同じ内部メソッド（アンダースコアで始まる）を使用していました。その後、関数のインターフェースが変更され、システムの別の部分からの呼び出しが壊れました。

逸話

プロジェクトの1つで、外部開発者のモジュールを修正し、その非エクスポートメソッドを直接呼び出しました。ディストリビューションを更新後、内部関数の名前が変更され、アプリケーションがクラッシュしました。