Comment Perl implémente-t-il les modificateurs d'accès pour les fonctions et les variables ? Pourquoi le langage ne contient-il pas un système public/privé/protégé habituel comme d'autres langages de programmation, et comment Perl limite-t-il l'accès aux données internes des modules ?

Réponse.

En Perl, il n'existe pas de système classique de modificateurs d'accès, comme public/privé/protégé. Tout le contrôle d'accès aux fonctions et aux données se fait par le biais de conventions et de la portée des variables.

• Pour limiter l'accès aux variables dans un module, on utilise le mot-clé my (visibilité lexicale au sein du fichier ou du bloc) et l'exportation de symboles (via Exporter ou ses propres mécanismes).
• Les sous-programmes non exportés à l'extérieur (@EXPORT, @EXPORT_OK) restent par défaut "internes" au module, bien qu'ils puissent toujours être appelés explicitement avec le préfixe de package si on le souhaite.
• Les fonctions et variables internes sont généralement précédées par un symbole de soulignement (_internal_sub), ce qui constitue une convention de confidentialité.

Exemple :

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

my $secret = 123; # Pas accessible de l'extérieur

sub public_func {
    _internal_func();
}

sub _internal_func {
    print "Ceci est interne !
";
}

1;

Question piège.

Quelles mesures protègent une fonction privée d'un module Perl contre les appels externes ? Ne peut-on pas l'appeler directement ?

Réponse : En réalité, toutes les sous-programmes d'un package peuvent être appelées explicitement avec le nom complet : MyLib::_internal_func(). Perl ne limite pas cet appel techniquement — la protection n'est qu'à un niveau de convention.

Exemples d'erreurs réelles dues à l'ignorance des subtilités du sujet.

---

Histoire

Un développeur a exporté trop de fonctions depuis le module, oubliant de restreindre via @EXPORT_OK. En conséquence, les utilisateurs avaient accidentellement accès à des fonctions internes, ce qui a entraîné des conflits de noms et une utilisation incorrecte de l'API.

---

Histoire

Dans un grand projet, deux équipes ont utilisé la même méthode interne (commençant par _), pensant qu'elle était privée. Plus tard, ils ont modifié l'interface de la fonction, ce qui a cassé les appels depuis une autre partie du système.

---

Histoire

Dans l'un des projets, ils ont modifié un module d'un développeur externe, appelant directement ses méthodes non exportées. Après la mise à jour de la distribution, le module a cessé de fonctionner car les noms internes des fonctions avaient changé, ce qui a fait planter l'application.