Perl Language
Packages et modules

Syntaxe

• require Module :: Name; # Requis par nom de @INC
• nécessite "path / to / file.pm"; # Requis par chemin relatif depuis @INC
• utiliser Module :: Name; # require et import par défaut à BEGIN
• utilisez Module :: Name (); # requis et pas d'importation à BEGIN
• utiliser Module :: Name (@ARGS); # nécessite et importe avec args à BEGIN
• utiliser Module :: Name VERSION; # demande, contrôle de version et importation par défaut à BEGIN
• utiliser Module :: Name VERSION (); # demande, contrôle de la version et pas d'importation à BEGIN
• utilisez Module :: Name VERSION (@ARGS); # requis, contrôle de version, import avec args à BEGIN
• faire "path / to / file.pl"; # charger et évaluer le fichier donné

Exécuter le contenu d'un autre fichier

do './config.pl';

Cela lira le contenu du fichier config.pl et l'exécutera. (Voir aussi: perldoc -f do .)

NB: Evitez de do sauf si vous jouez au golf ou quelque chose comme il n'y a pas de vérification d'erreur. Pour inclure des modules de bibliothèque, utilisez require ou use .

Chargement d'un module à l'exécution

require Exporter;

Cela garantira que le module Exporter est chargé à l'exécution s'il n'a pas déjà été importé. (Voir aussi: perldoc -f require .)

NB: La plupart des utilisateurs doivent use modules plutôt que require les require . Contrairement à use , require n'appelle pas la méthode d'importation du module et s'exécute à l'exécution, pas pendant la compilation.

Cette façon de charger les modules est utile si vous ne pouvez pas décider des modules dont vous avez besoin avant l'exécution, comme avec un système de plug-in:

package My::Module;
my @plugins = qw( One Two );
foreach my $plugin (@plugins) {
    my $module = __PACKAGE__ . "::Plugins::$plugin";
    $module =~ s!::!/!g;
    require "$module.pm";
}

Cela essaierait de charger My::Package::Plugins::One et My::Package::Plugins::Two . @plugins devrait bien sûr provenir d'une entrée utilisateur ou d'un fichier de configuration pour que cela ait un sens. Notez l'opérateur de substitution s!::!/!g qui remplace chaque paire de deux-points par une barre oblique. En effet , vous pouvez charger des modules en utilisant la syntaxe du nom du module familier de l' use que si le nom du module est un bareword. Si vous transmettez une chaîne ou une variable, elle doit contenir un nom de fichier.

En utilisant un module

use Cwd;

Cela importera le module Cwd au moment de la compilation et importera ses symboles par défaut, c'est-à-dire que certaines des variables et fonctions du module seront disponibles pour le code qui l'utilise. (Voir aussi: perldoc -f use .)

Généralement, cela fera la bonne chose. Cependant, vous voudrez parfois contrôler les symboles importés. Ajoutez une liste de symboles après le nom du module à exporter:

use Cwd 'abs_path';

Si vous faites cela, seuls les symboles que vous spécifiez seront importés (c.-à-d. Que le jeu par défaut ne sera pas importé).

Lors de l'importation de plusieurs symboles, il est idiomatique d'utiliser la construction de liste qw() :

use Cwd qw(abs_path realpath);

Certains modules exportent un sous-ensemble de leurs symboles, mais on peut leur demander d’exporter tout avec :all :

use Benchmark ':all';

(Notez que tous les modules ne reconnaissent pas ou n’utilisent pas la balise :all ).

Utiliser un module dans un répertoire

use lib 'includes';
use MySuperCoolModule;

use lib 'includes'; ajoute le répertoire relatif includes/ comme autre chemin de recherche de module dans @INC . Supposons donc que vous avez un fichier de module MySyperCoolModule.pm intérieur de MySyperCoolModule.pm includes/ , qui contient:

package MySuperCoolModule;

Si vous le souhaitez, vous pouvez regrouper autant de modules que vous le souhaitez dans un même répertoire et les rendre accessibles avec une seule instruction use lib .

À ce stade, l'utilisation des sous-routines du module nécessitera de préfixer le nom du sous-programme avec le nom du package:

MySuperCoolModule::SuperCoolSub_1("Super Cool String");

Pour pouvoir utiliser les sous-programmes sans préfixe, vous devez exporter les noms des sous-programmes afin qu'ils soient reconnus par le programme qui les appelle. L'exportation peut être configurée pour être automatique, donc:

package MySuperCoolModule;
use base 'Exporter';
our @EXPORT = ('SuperCoolSub_1', 'SuperCoolSub_2');

Ensuite, dans le fichier qui use le module, ces sous-routines seront automatiquement disponibles:

use MySuperCoolModule;
SuperCoolSub_1("Super Cool String");

Ou vous pouvez configurer le module pour exporter conditionnellement des sous-routines, donc:

package MySuperCoolModule;
use base 'Exporter';
our @EXPORT_OK = ('SuperCoolSub_1', 'SuperCoolSub_2');

Dans ce cas, vous devez explicitement demander l'exportation des sous-routines souhaitées dans le script use le module:

use MySuperCoolModule 'SuperCoolSub_1';
SuperCoolSub_1("Super Cool String");

CPAN.pm

CPAN.pm est un module Perl qui permet d'interroger et d'installer des modules à partir de sites CPAN.

Il supporte le mode interactif invoqué avec

cpan

ou

perl -MCPAN -e shell

Interroger les modules

De nom:

cpan> m MooseX::YAML

Par une expression régulière contre le nom du module:

cpan> m /^XML::/

Remarque: pour activer un pager ou rediriger vers un fichier | ou > redirection de shell (les espaces sont obligatoires autour des | et > ), par exemple: m /^XML::/ | less

Par distribution:

cpan> d LMC/Net-Squid-Auth-Engine-0.04.tar.gz

Installation de modules

De nom:

cpan> install MooseX::YAML

Par distribution:

cpan> install LMC/Net-Squid-Auth-Engine-0.04.tar.gz

Liste tous les modules installés

En ligne de commande:

cpan -l

À partir d'un script Perl:

use ExtUtils::Installed;
my $inst = ExtUtils::Installed->new();
my @modules = $inst->modules();