Perl moderne : 2014

Les tests Perl commencent avec le module standard Test::More et sa fonction ok(). ok() prend deux paramètres, une valeur booléenne et une chaîne qui décrit l'objectif du test :

ok(   1, 'le nombre un devrait être vrai'               );
ok(   0, '... et le zéro ne le devrait pas'             );
ok(  '', 'la chaîne vide devrait être fausse'           );
ok( '!', '... et une chaîne non vide ne le devrait pas' );

done_testing();

Toute condition que vous pouvez tester dans votre programme peut finalement se résumer à une valeur binaire. Chaque assertion de test est une simple question avec une réponse par oui ou par non : est-ce que ce code se comporte comme je voulais ? Un programme complexe peut avoir des milliers de conditions individuelles. Aucun problème. Vous pouvez tester chacune de ces conditions, si vous souhaitez faire cet effort. Isoler des comportements particuliers dans des assertions individuelles vous aide à déboguer les erreurs de codage et de compréhension, surtout lorsque vous modifierez le code dans le futur.

La fonction done_testing() indique à Test::More que le programme a exécuté toutes les assertions demandées. Si le programme a rencontré une exception lors de l'exécution ou s'est arrêté de façon inattendue avant l'appel à done_testing(), le module de test vous informe que quelque chose s'est mal passé. Sans un mécanisme comme done_testing(), comment pourriez-vous le savoir ? Certes, cet exemple de code est trop simple pour échouer, mais le code qui est trop simple pour échouer échoue beaucoup plus souvent que vous ne le voulez.

use Test::More tests => 4;

ok(   1, 'le nombre un devrait être vrai'               );
ok(   0, '... et le zéro ne le devrait pas'             );
ok(  '', 'la chaîne vide devrait être fausse'           );
ok( '!', '... et une chaîne non vide ne le devrait pas' );

Cet exemple de fichier de test est un programme Perl complet qui produit la sortie :

ok 1 - le nombre un devrait être vrai
not ok 2 - ... et le zéro ne le devrait pas
#   Failed test '... et le zéro ne le devrait pas'
#   at truth_values.t line 4.
not ok 3 - la chaîne vide devrait être fausse
#   Failed test 'la chaîne vide devrait être fausse'
#   at truth_values.t line 5.
ok 4 - ... et une chaîne non vide ne le devrait pas
# Looks like you failed 2 tests of 4.

Cet affichage utilise un format de sortie de test appelé TAP, Test Anything Protocol (http://testanything.org/). Les tests TAP échoués produisent des messages de diagnostic comme une aide au débogage.

Le résultat affiché par ce petit exemple est facile à comprendre, mais cela peut devenir rapidement compliqué. Dans la plupart des cas, vous voulez savoir si tous les tests ont réussi ou le détail des échecs. Le module standard TAP::Harness interprète le TAP. Son programme prove qui lui est associé exécute des tests et affiche uniquement l'information la plus pertinente :

$ prove truth_values.t
truth_values.t .. 1/?
#   Failed test '... et le zéro ne le devrait pas'
#   at truth_values.t line 4.

#   Failed test 'la chaîne vide devrait être fausse'
#   at truth_values.t line 5.
# Looks like you failed 2 tests of 4.
truth_values.t .. Dubious, test returned 2
    (wstat 512, 0x200)
Failed 2/4 subtests

Test Summary Report
-------------------
truth_values.t (Wstat: 512 Tests: 4 Failed: 2)
Failed tests:  2-3

Cela fait beaucoup d'information en sortie pour afficher ce qui est déjà évident : le deuxième et le troisième test échouent parce que le zéro et la chaîne vide ont la valeur fausse. Heureusement, il est facile à corriger par coercition booléenne ces tests qui échouent (Coercition booléenneCoercition booléenne) :

ok(   ! 0, '... et le zéro ne le devrait pas'   );
ok(  ! '', 'la chaîne vide devrait être fausse' );

Avec ces deux modifications, prove affiche maintenant :

$ prove truth_values.t
truth_values.t .. ok
All tests successful.

alias proveall='prove -j9 --state=slow,save -lr t'

Même si le cœur de tous les tests automatisés est la condition booléenne « est-ce vrai ou faux ? », il est fastidieux de tout réduire à cette condition booléenne et le diagnostic pourrait être meilleur. Test::More offre plusieurs autres fonctions pratiques d'assertion.

La fonction is() compare deux valeurs en utilisant l'opérateur eq de Perl. Si les valeurs sont égales, le test réussit :

is(       4, 2 + 2, 'l\'addition devrait marcher' );
is( 'crêpe',   100, 'les crêpes sont numériques'  );

Comme vous vous en doutez sans doute, le premier test réussit et le second échoue avec un message de diagnostic :

t/is_tests.t .. 1/2
#   Failed test 'les crêpes sont numériques'
#   at t/is_tests.t line 8.
#          got: 'crêpe'
#     expected: '100'
# Looks like you failed 1 test of 2.

Là où ok() ne fournit que le numéro de ligne du test échoué, is() affiche les valeurs attendues et reçues.

is() applique un contexte scalaire implicite à ses valeurs (PrototypesPrototypes). Cela signifie, par exemple, que vous pouvez vérifier le nombre d'éléments dans un tableau sans évaluer explicitement le tableau dans un contexte scalaire... et vous pouvez omettre les parenthèses :

my @cousins = qw( Rick Kristen Alex Kay Eric Corey );
is @cousins, 6, 'Je devrais avoir seulement six cousins';

... bien que certaines personnes préfèrent écrire scalar @cousins par souci de clarté.

La fonction inverse isnt() de Test::More compare deux valeurs en utilisant l'opérateur ne, et retourne la valeur vraie si elles ne sont pas égales. Elle aussi fournit un contexte scalaire à ses opérandes.

is() et isnt() appliquent toutes les deux des comparaisons de chaînes avec les opérateurs eq et ne. C'est presque toujours une bonne chose, mais utilisez la fonction cmp_ok() — qui vous oblige à fournir un opérateur de comparaison spécifique — pour les valeurs complexes telles que des objets avec surcharge (SurchargeSurcharge) ou des variables dualvar (DualvarsDualvars) :

cmp_ok( 100, $solde_actuel, '<=', 
    'Je devrais avoir au moins 100 €' );

cmp_ok( $singe, $grand_singe, '==', 
    'La conversion en nombre des simiens devrait marcher' );

Les classes et les objets fournissent leurs propres façons intéressantes d'interagir avec les tests. Testez qu'une classe ou un objet hérite d'une autre classe (HéritageHéritage) avec isa_ok() :

my $singezilla = RobotSinge->new;
isa_ok( $singezilla, 'Robot' );
isa_ok( $singezilla, 'Singe' );

isa_ok() fournit son propre message de diagnostic en cas d'échec.

can_ok() vérifie si une classe ou un objet peuvent invoquer la méthode ou les méthodes demandées :

can_ok( $singezilla, 'manger_banane' );
can_ok( $singezilla, 'transformer', 'detruire_tokyo' );

La fonction is_deeply() compare deux références pour s'assurer que leur contenu est identique :

use Clone;

my $nombres   = [ 4, 8, 15, 16, 23, 42 ];
my $clonenbre = Clone::clone( $nombres );

is_deeply( $nombres, $clonenbre,
     'clone() devrait produire des éléments identiques' );

Si la comparaison échoue, Test::More fera de son mieux pour fournir un diagnostic raisonnable indiquant la position de la première inégalité entre les structures. Voir les modules Test::Differences et Test::Deep du CPAN pour des tests plus configurables.

Test::More dispose de plusieurs fonctions de test, mais celles que nous venons de voir sont les plus utiles.

Les distributions du CPAN doivent en principe inclure un répertoire t/contenant un ou plusieurs fichiers de test nommés avec l'extension .t. Lorsque vous construisez une distribution avec le module Module::Build ou ExtUtils::MakeMaker, l'étape de test exécute tous les fichiers t/*.t, résume leur sortie et réussit ou échoue sur l'ensemble des résultats de la suite de tests. Il n'y a aucune ligne directrice concrète sur la façon de gérer le contenu des fichiers .t individuels, mais deux stratégies sont populaires :

• chaque fichier .t doit correspondre à un fichier .pm ;
• chaque fichier .t doit correspondre à une fonctionnalité.

Une approche hybride est plus flexible ; un test peut vérifier si tous vos modules compilent, tandis que d'autres tests démontrent que chaque module se comporte comme prévu. Lorsque votre projet grandit, la seconde approche est plus facile à gérer. Gardez vos fichiers de test petits et ciblés et ils seront plus faciles à maintenir.

Des fichiers séparés de test peuvent également accélérer le développement. Si vous ajoutez à votre RobotSinge la capacité de souffler du feu, vous voudriez peut-être exécuter uniquement le fichier de test t/souffler_feu.t. Lorsque la fonctionnalité marche comme vous voulez, exécutez toute la série de tests pour vérifier si les changements locaux n'ont aucun effet global indésirable.

Test::More s'appuie sur un mécanisme sous-jacent de test connu sous le nom de Test::Builder. Ce dernier module gère le plan de test et coordonne la sortie du test dans le TAP. Cette conception permet aux multiples modules de test de partager le même mécanisme Test::Builder. Par conséquent, le CPAN a des centaines de modules de test disponibles et ils peuvent travailler tous ensemble dans le même programme.

• Test::Fatal permet de vérifier si votre code signale (ou pas) des exceptions de façon appropriée. Vous pouvez également rencontrer Test::Exception.
• Test::MockObject et Test::MockModule permettent de tester des interfaces difficiles en les simulant (émulation produisant des résultats différents).
• Test::WWW::Mechanize permet de tester des applications Web, tandis que Plack::Test, Plack::Test::Agent et la sous-classe Test::WWW::Mechanize::PSGI peuvent le faire sans utiliser un serveur Web externe.
• Test::Database fournit des fonctions pour tester l'utilisation et les dysfonctionnements des bases de données. DBICx::TestDatabase aide à créer des schémas temporaires de bases de données de test construits avec DBIx::Class.
• Test::Class offre un mécanisme alternatif pour organiser des suites de tests. Il vous permet de créer des classes dans lesquelles des méthodes spécifiques groupent des tests. Vous pouvez hériter des classes de test tout comme les classes de votre code héritent les unes des autres. C'est un excellent moyen de réduire la duplication dans les suites de tests. Voir l'excellente série Test::Class de Curtis « Ovid » Poe http://www.modernperlbooks.com/mt/2009/03/organizing-test-suites-with-testclass.html. La distribution récente Test::Routine offre des possibilités similaires à travers l'utilisation de Moose (MooseMoose).
• Test::Differences teste l'égalité des chaînes et structures de données et affiche toute différence dans ses diagnostics. Test::LongString ajoute des assertions similaires.
• Test::Deep teste l'équivalence des structures de données imbriquées (Structures de données imbriquéesStructures de données imbriquées).
• Devel::Cover analyse l'exécution de votre suite de tests et fait un rapport sur la quantité de votre code testé effectivement. En général, plus c'est couvert, mieux c'est — bien que 100 % ne soit pas toujours possible, 95 % c'est beaucoup mieux que 80 %.
• Test::Most regroupe plusieurs modules utiles de test en un seul module parent. Il permet d'économiser temps et effort.

Voir le projet Perl QA (http://qa.perl.org/) pour plus d'informations sur les tests en Perl.

Utilisez la commande interne warn pour émettre un avertissement :

warn 'Quelque chose s\'est mal passé !';

warn imprime une liste de valeurs dans le descripteur de fichier STDERR (Entrée et sortieEntrée et sortie). Perl concaténera le nom de fichier et le numéro de la ligne ayant appelé warn sauf si le dernier élément de la liste se termine par un saut de ligne.

Le module standard Carp étend les mécanismes d'alerte de Perl. Sa fonction carp() signale un avertissement dans la perspective du code appelant. Étant donnée une fonction comme :

use Carp 'carp';

sub seulement_deux_arguments
{
    my ($lop, $rop) = @_;
    carp( 'Trop d\'arguments fournis' ) if @_ > 2;
    ...
}

... l'avertissement d'arité (AritéArité) comprendra le nom et le numéro de ligne du code appelant, pas seulement_deux_arguments(). La méthode cluck() de Carp est similaire, mais elle produit une trace de tous les appels de fonction jusqu'à la fonction en cours.

Le mode verbeux de Carp ajoute les traces de tous les avertissements produits par carp() et croak() (Rapports d'erreursRapports d'erreurs) à travers l'ensemble du programme :

$ perl -MCarp=verbose my_prog.pl

Utilisez Carp au lieu de warn ou die lors de l'écriture des modules (ModulesModules).

Parfois, des programmes plus anciens utilisent l'argument de ligne de commande -w, qui active les avertissements tout au long du programme, même dans les modules externes écrits et maintenus par d'autres personnes. C'est tout ou rien — mais cela peut vous être utile si vous avez le temps et l'énergie d'éliminer les avertissements réels et potentiels tout au long du code source.

L'approche moderne consiste à utiliser le pragma warnings ou un équivalent, comme use Modern::Perl;. Cela active les avertissements dans les portées lexicales. Si vous avez utilisé warnings dans une portée, vous indiquez que le code ne devrait produire normalement aucun avertissement.

-w, -W et -X affectent tous la valeur de la variable globale $^W. Le code écrit avant l'introduction du pragma warnings avec Perl 5.6.0 — au printemps 2000, pour que vous sachiez que c'est vieux — peut localiser $^W pour supprimer certains avertissements à l'intérieur d'une portée donnée.

Pour désactiver certains avertissements particuliers à l'intérieur d'une portée, utilisez no warnings; avec une liste d'arguments. L'omission de la liste d'arguments désactive tous les avertissements à l'intérieur de cette portée.

perldoc perllexwarn répertorie toutes les catégories d'avertissements comprises par votre version de Perl. La plupart d'entre eux représentent des conditions vraiment intéressantes, mais certains peuvent être inutiles dans vos circonstances particulières. Par exemple, l'avertissement recursion se produira si Perl détecte qu'une fonction s'est appelée elle-même plus de cent fois. Si vous êtes confiant dans votre capacité à écrire des conditions d'arrêt de la récursion, vous pouvez désactiver cet avertissement dans la portée de la récursion (bien que les appels terminaux puissent être préférables ; Appels de fonctions et récursion terminaleAppels de fonctions et récursion terminale).

Si vous générez du code (Génération de codeGénération de code) ou redéfinissez des symboles localement, vous pouvez souhaiter désactiver les avertissements redefine.

Certains développeurs Perl expérimentés désactivent les avertissements de type Use of uninitialized value dans le code qui traite des chaînes et qui concatène des valeurs provenant de plusieurs sources. Si vous êtes prudent sur l'initialisation de vos variables, vous pouvez ne jamais avoir besoin de désactiver cet avertissement, mais parfois l'avertissement gêne l'écriture du code concis dans votre style local.

Si votre projet considère les avertissements aussi onéreux que les erreurs, vous pouvez les rendre fatals. Afin de transformer tous les avertissements en exceptions au sein d'une portée lexicale :

use warnings FATAL => 'all';

Vous pouvez également rendre fatales des catégories spécifiques d'avertissements, telles que l'utilisation de constructions obsolètes :

use warnings FATAL => 'deprecated';

Avec une bonne discipline, cela peut produire un code très robuste — mais soyez prudent. De nombreux avertissements proviennent des conditions d'exécution. Si votre suite de tests ne parvient pas à identifier tous les avertissements que vous pourriez rencontrer, votre programme peut s'arrêter à cause des exceptions d'exécution non interceptées. Gardez à l'esprit que les versions les plus récentes de Perl peuvent ajouter de nouveaux avertissements et les avertissements customisés seront également fatals (Enregistrer vos propres avertissementsEnregistrer vos propres avertissements). Si vous activez les avertissements fatals, faites-le uniquement dans le code que vous contrôlez et jamais dans le code d'une bibliothèque censée être utilisée par d'autres personnes.

Si vous êtes prêt à y travailler, vous pouvez intercepter des avertissements comme vous le feriez pour des exceptions. La variable %SIG (voir perldoc perlvar) contient des gestionnaires pour les signaux hors bande lancés par Perl ou par votre système d'exploitation. Affectez à $SIG{__WARN__} une référence de fonction pour intercepter un avertissement :

{
    my $warning;
    local $SIG{__WARN__} = sub { $warning .= shift };

    # faites quelque chose de risqué
    ...

    say "Intercepté l'avertissement :\n$warning" if $warning;
}

Dans le gestionnaire d'avertissements, le premier argument est le message de l'avertissement. Certes, cette technique est moins utile que la désactivation lexicale des avertissements, mais elle peut convenir à la bonne utilisation de modules de test tels que Test::Warnings du CPAN, où le texte de l'avertissement est important.

Faites attention, car %SIG est globale. localisez-la dans la portée la plus petite possible, mais comprenez qu'elle reste toujours une variable globale.

Le pragma warnings::register vous permet de créer vos propres avertissements afin que les utilisateurs de votre code puissent les activer et désactiver dans les portées lexicales. Dans un module, utilisez le pragma warnings::register ainsi :

package Singe::Effrayant;

use warnings::register;

Cela va créer une nouvelle catégorie d'avertissements du nom du paquetage Singe::Effrayant. Activez ces avertissements avec use warnings 'Singe::Effrayant' et désactivez-les avec no warnings 'Singe::Effrayant'.

Utilisez warnings::enabled() pour tester si la portée lexicale de l'appelant a activé une catégorie d'avertissements. Utilisez warnings::warnif() pour produire un avertissement uniquement si les avertissements sont en vigueur. Par exemple, pour produire un avertissement dans la catégorie deprecated :

package Singe::Effrayant;

use warnings::register;

sub import
{
    warnings::warnif( 'deprecated',
        'empty imports from ' . __PACKAGE__ .
        ' are now deprecated' )
    unless @_;
}

Voir perldoc perllexwarn pour plus de détails.

Un descripteur de fichier représente l'état courant d'un canal spécifique d'entrée ou de sortie. Chaque programme Perl a trois descripteurs de fichiers standard disponibles, STDIN (l'entrée au programme), STDOUT (la sortie du programme), et STDERR (la sortie d'erreurs du programme). Par défaut, tout ce que vous affichez en sortie avec print ou say va dans STDOUT, tandis que les erreurs et les avertissements vont dans STDERR. Cette séparation de la sortie vous permet de rediriger la sortie utile et les erreurs vers deux endroits différents — un fichier de sortie et les journaux d'erreurs, par exemple.

Utilisez la commande interne open pour obtenir un descripteur de fichier. Pour ouvrir un fichier en lecture :

open my $fh, '<', 'nomFichier' 
    or die "Impossible de lire '$nomFichier': $!\n";

Le premier opérande est une variable lexicale qui contiendra le descripteur de fichier résultant. Le deuxième opérande est le mode d'ouverture du fichier, qui détermine le type de l'opération sur le descripteur de fichier (lecture, écriture, ou ajout à la fin, par exemple). L'opérande final est le nom du fichier. Si l'ouverture échoue, la clause die va lancer une exception, avec la raison de l'échec dans la variable magique $!.

Vous pouvez ouvrir des fichiers pour y écrire, ajouter à la fin, lire et écrire, et plus encore. Les modes d'ouverture de fichiers les plus importants sont les suivants :

Vous pouvez même créer des descripteurs de fichiers qui lisent ou écrivent dans de simples scalaires Perl, en utilisant n'importe quel mode de fichier existant :

open my $lire_fh,   '<', \$entree_truquee;
open my $ecrire_fh, '>', \$sortie_capturee;

faire_quelque_chose_de_genial( $lire_fh, $ecrire_fh );

perldoc perlopentut explique en détail les usages plus exotiques de open, y compris sa capacité de lancer et contrôler d'autres processus, ainsi que l'utilisation de sysopen pour contrôle plus fin sur l'entrée et la sortie. perldoc perlfaq5 inclut des exemples de code permettant de réaliser de nombreuses tâches courantes d'entrée/sortie.

X-C-1-a. Unicode, couches E/S et modes de fichier▲

open my $entree_fh,  '>:encoding(UTF-8)', $fichier_en_entree;

open my $sortie_fh, '<:encoding(UTF-8)', $fichier_en_sortie;

X-C-1-b. Fonction open à deux arguments▲

open my $fh, "> $un_fichier"
    or die "Impossible d'écrire dans '$un_fichier': $!\n";

X-C-1-c. Lire des fichiers▲

open my $fh, '<', 'un_fichier';

while (<$fh>)
{
    chomp;
    say "Lire une ligne '$_'";
}

open my $fh, '<', 'un_fichier';

while (defined($_ = <$fh>))
{
    chomp;
    say "Lire une ligne '$_'";
    last if eof $fh;
}

open my $fh, '<', $nomFichier;

while (my $ligne = <$fh>)
{
    chomp $ligne;
    ...
}

X-C-1-d. Écrire dans des fichiers▲

open my $out_fh, '>', 'output_file.txt';

print $out_fh "Voici une ligne de text\n";
say   $out_fh "... et en voici une autre";

my @princes = qw( Corwin Eric Random ... );

print @princes;
print join( $,, @princes ) . $\;

X-C-1-e. Fermer des fichiers▲

use autodie qw( open close );

open my $fh, '>', $fichier;

...

close $fh;

X-C-1-f. Variables spéciales de gestion des fichiers▲

open my $fh, '>', 'pecan.log';
$fh->autoflush( 1 );

...

Travailler avec des répertoires est analogue à travailler avec des fichiers, sauf que vous ne pouvez pas écrire dans des répertoires. Au lieu de cela, vous enregistrez, déplacez, renommez et supprimez des fichiers. Ouvrez un descripteur de répertoire avec la commande interne opendir :

opendir my $dirh, '/home/singedompteur/taches/';

La commande interne readdir lit un répertoire. Comme avec readline, vous pouvez parcourir le contenu des répertoires un par un ou vous pouvez les affecter à un tableau en une seule fois :

# itération
while (my $file = readdir $dirh)
{
    ...
}

# aplatissement en une liste, affectation à un tableau
my @files = readdir $autre_dirh;

Perl 5.12 a ajouté une fonctionnalité où readdir définit $_ dans une boucle while :

use 5.012;

opendir my $dirh, 'taches/cirque/';

while (readdir $dirh)
{
    next if /^\./;
    say "Trouvé une tâche $_!";
}

La curieuse expression régulière dans cet exemple permet d'ignorer ce qu'on appelle des fichiers cachés sur les systèmes de type Unix, où un point en début de leur nom les empêche par défaut d'apparaître dans l'affichage du contenu de répertoires. Elle permet d'ignorer également les deux fichiers spéciaux . et .., qui représentent respectivement le répertoire courant et le répertoire parent.

Les noms retournés par readdir sont relatifs au répertoire même. Autrement dit, si le répertoire tâches/ contient trois fichiers nommés manger, boire, et sois_singe, readdir retournera manger, boire et sois_singe et non tâches/manger, tâches/boire, et tâches/sois_singe. En revanche, un chemin absolu est un chemin d'accès complet à son système de fichiers.

Fermez un descripteur de répertoire en le laissant sortir de la portée ou avec la commande interne closedir.

X-C-2-a. Manipuler des chemins de fichier▲

use Path::Class;

my $repas = dir( 'taches', 'cuisiner' );
my $file  = file( 'taches', 'sante', 'robots.txt' );

my $diner      = $repas->file( 'calzone_vegetarienne' );
my $robots_dir = $liste_robots->dir;

my $dir_fh    = $dir->open;
my $robots_fh = $liste_robots->open( 'r' )
                    or die "Ouverture échouée : $!";

my $contenu = lire_dans_nomFichier( "$diner" );

En plus de lire et écrire des fichiers, vous pouvez également les manipuler comme vous le feriez directement depuis une ligne de commande ou d'un gestionnaire de fichiers. Les opérateurs de test de fichier, collectivement appelés opérateurs -X, examinent les attributs des fichiers et répertoires. Pour tester si un fichier existe :

say 'Present !' if -e $nomFichier;

L'opérateur -e a un seul opérande, le nom d'un fichier ou un descripteur de fichier ou de répertoire. Si le fichier existe, l'expression retournera une valeur vraie. perldoc -f -X répertorie tous les autres tests de fichiers ; les plus populaires sont :

• -f
  qui retourne la valeur vraie si son opérande est un simple fichier ;
• -d
  qui retourne la valeur vraie si son opérande est un répertoire ;
• -r
  qui retourne la valeur vraie si les autorisations du fichier de son opérande permettent la lecture par l'utilisateur courant ;
• -s
  qui renvoie la valeur vraie si son opérande est un fichier non vide.

Recherchez la documentation de ces opérateurs avec perldoc -f -r, par exemple.

La commande interne rename peut renommer un fichier ou le déplacer entre des répertoires. Elle prend deux opérandes, l'ancien et le nouveau chemin du fichier :

rename 'etoile_de_la_mort.txt', 'puits_de_carbone.txt';

# ou plus élégant :
rename 'etoile_de_la_mort' => 'puits_de_carbone .txt';

Il n'y a pas de commande interne pour copier un fichier, mais le module standard File::Copy fournit à la fois les fonctions copy() et move(). Utilisez la commande interne unlink pour supprimer un ou plusieurs fichiers. (La commande interne delete supprime un élément d'un hachage, pas un fichier du système de fichiers.) Ces fonctions et commandes internes retournent toutes la valeur vraie pour succès et initialisent $! en cas d'erreur.

Perl suit son répertoire de travail courant. Par défaut, c'est le répertoire actif d'où vous avez lancé le programme. La fonction cwd() du module standard Cwd retourne le nom du répertoire de travail courant. La commande interne chdir tente de modifier le répertoire de travail courant. Pour travailler avec des fichiers ayant des chemins relatifs, il est essentiel de travailler à partir du répertoire correct.

Lorsque vous chargez un module avec use, Perl le charge à partir du disque, puis appelle sa méthode import(), en passant les arguments que vous avez éventuellement fournis. Par convention, la méthode import() d'un module prend une liste des noms et exporte des fonctions et autres symboles dans l'espace de noms appelant. Ce n'est qu'une convention ; un module peut refuser de fournir une méthode import(), ou sa méthode import() peut avoir d'autres comportements. Des pragmas (PragmasPragmas) tels que strict utilisent les arguments pour modifier le comportement de la portée lexicale appelante au lieu d'exporter des symboles :

use strict;
# ... appelle strict->import()

use CGI ':standard';
# ... appelle CGI->import( ':standard' )

use feature qw( say switch );
# ... appelle feature->import( qw( say switch ) )

La commande interne no appelle la méthode unimport() d'un module, si elle existe, en passant tous les arguments. Cela est plus fréquent avec les pragmas qui introduisent ou modifient un comportement par le biais de import() :

use strict;
# aucune référence symbolique, aucun mot nu
# exige la déclaration des variables

{
    no strict 'refs';
    # références symboliques permises
    # les 'subs' et 'vars' de strict toujours en vigueur
}

Tant use que no prennent effet lors de la compilation, de sorte que :

use Module::Name qw( liste arguments );

... est identique à :

BEGIN
{
    require 'Module/Name.pm';
    Module::Name->import( qw( liste arguments ) );
}

De la même façon :

no Module::Name qw( liste arguments );

... est identique à :

BEGIN
{
    require 'Module/Name.pm';
    Module::Name->unimport(qw( liste d'arguments ));
}

... y compris require du module.

Vous pouvez appeler directement import() et unimport(), bien qu'il soit peu logique de le faire en dehors d'un bloc BEGIN ; une fois la compilation terminée, les effets de import() ou unimport() peuvent être limités.

Tant use que require respectent la casse (c'est-à-dire la distinction entre majuscules et minuscules). Bien que Perl connaisse la différence entre strict et Strict, votre combinaison de système d'exploitation et système de fichiers ne la connaît peut-être pas. Si vous écrivez use Strict;, Perl ne trouvera pas strict.pm sur un système de fichiers sensible à la casse. Avec un système de fichiers insensible à la casse, Perl chargera volontiers Strict.pm, mais rien ne se passera quand il essaie d'appeler Strict->import(). (strict.pm déclare un paquetage nommé strict.)

Les programmes portables font attention à la casse, même s'ils n'en ont pas besoin.

Un module peut rendre les symboles globaux de paquetage disponibles à d'autres paquetages à travers un processus connu sous le nom d'exportation — souvent en appelant import() implicitement ou directement.

Le module standard Exporter est le moyen habituel pour exporter les symboles d'un module. Exporter repose sur la présence des variables globales de paquetages — en particulier @EXPORT_OK et @EXPORT, qui contiennent une liste de symboles à exporter sur demande.

Examinons un module SingeEtrange::Utilites qui offre plusieurs fonctions autonomes utilisables dans tout le système :

package SingeEtrange::Utilites;

use Exporter 'import';

our @EXPORT_OK = qw( round translate screech );

...

Tout autre programme ou module peut maintenant utiliser ce module et éventuellement, importer une partie ou chacune des trois fonctions exportées. Vous pouvez également exporter des variables :

push @EXPORT_OK, qw( $aragnee $saki $ecureuil );

Exportez des symboles par défaut en les énumérant dans @EXPORT au lieu de @EXPORT_OK :

our @EXPORT = qw( singe_danse singe_dort );

... de sorte que toute instruction use SingeEtrange::Utilities; importera les deux fonctions. Sachez cependant que le fait de spécifier des symboles à importer conduira à la non-importation des symboles par défaut ; vous obtenez seulement ce que vous demandez. Pour charger un module sans importer les symboles, utilisez une liste vide explicite :

# rend le module disponible, mais n'importe rien
use StrangeMonkey::Utilities ();

Indépendamment de toute liste d'importations, vous pouvez toujours appeler des fonctions depuis un autre paquetage avec leurs noms complets :

SingeEtrange::Utilities::cri();

Perl ne vous oblige pas à utiliser des modules, paquetages ou espaces de noms. Vous pouvez mettre tout votre code dans un seul fichier .pl ou dans plusieurs fichiers .pl que vous appelez avec require selon vos besoins. Vous avez la possibilité de gérer votre code de la façon la plus appropriée, compte tenu de votre style de développement, du formalisme, du risque et de l'importance du projet, ainsi que de votre expérience et de votre facilité à déployer du code.

Cela dit, un projet ayant plus de quelques centaines de lignes de code gagne à être organisé en modules :

• les modules aident à imposer une séparation logique entre des entités distinctes du système ;
• les modules offrent une interface de séparation, procédurale ou OO ;
• les modules encouragent une organisation naturelle du code source ;
• l'écosystème de Perl possède de nombreux outils consacrés à la création, au maintien, à l'organisation et au déploiement des modules et des distributions ;
• les modules fournissent un mécanisme de réutilisation du code.

Même si vous n'utilisez pas une approche orientée objet, la modélisation de chaque entité ou responsabilité distincte dans votre système avec son propre module rassemble le code lié et sépare le code séparé.

Outre un ou plusieurs modules, une distribution comprend plusieurs autres fichiers et répertoires :

• Build.PL ou Makefile.PL, un programme pilote permettant de configurer, construire, tester, regrouper et installer la distribution ;
• MANIFEST, une liste de tous les fichiers contenus dans la distribution. Cela permet aux outils de vérifier si la distribution est complète ;
• META.yml et/ou META.json, un fichier contenant des métadonnées à propos de la distribution et de ses dépendances ;
• README, une description de la distribution, son intention, et les informations sur son droit d'auteur et octroi de licences ;
• lib/, le répertoire contenant des modules Perl ;
• t/, un répertoire contenant des fichiers de test ;
• Changes, un fichier journal reprenant chaque changement significatif à la distribution.

Une distribution bien formée doit contenir un nom et un numéro de version unique (souvent obtenues de son module principal). Toute distribution que vous téléchargez à partir du réseau public CPAN doit se conformer à ces normes. Le service CPANTS (http://cpants.perl.org/) évalue si chaque distribution téléchargée respecte les lignes directrices et les conventions de paquetage et recommande des améliorations. Suivre les directives CPANTS ne signifie pas que le code fonctionne, mais que les outils de paquetage CPAN devraient comprendre la distribution.

Perl est livré en standard avec plusieurs outils pour gérer les distributions :

• CPAN.pm est le client officiel de CPAN. Bien que par défaut ce client installe des distributions du CPAN public, vous pouvez également l'utiliser sur votre propre dépôt logiciel à la place ou en plus du dépôt public ;
• Module::Build est une suite d'outils en pur Perl pour configurer, construire, installer et tester de distributions. Elle fonctionne avec les fichiers Build.PL ;
• ExtUtils::MakeMaker est un outil plus ancien, que Module::Build est destiné à remplacer. Il est encore largement utilisé, mais il est en mode maintenance et reçoit uniquement des corrections de bogues critiques. Il fonctionne avec les fichiers Makefile.PL ;
• Test::More (TestsTests) est le module fondamental et le plus largement utilisé pour écrire des tests automatisés pour les logiciels Perl ;
• TAP::Harness et prove (Exécuter des testsExécuter des tests) exécutent des tests et interprètent et communiquent leurs résultats.

En outre, plusieurs modules non standard du CPAN vous facilitent la vie en tant que développeur :

• App::cpanminus est un client CPAN sans configuration. Il gère les cas les plus courants, utilise peu de mémoire, et travaille rapidement ;
• App::perlbrew vous aide à gérer les installations multiples de Perl. Installez des nouvelles versions de Perl pour tests ou production, ou pour isoler des applications et leurs dépendances ;
• CPAN::Mini et la commande cpanmini vous permettent de créer votre propre miroir (privé) du réseau public CPAN. Vous pouvez ajouter dans ce référentiel vos propres distributions et gérer les versions des modules publics disponibles dans votre organisation ;
• Dist::Zilla automatise à distance les tâches de distribution courantes. Comme il utilise soit Module::Build, soit ExtUtils::MakeMaker, il peut remplacer votre utilisation directe de ceux-ci. Voir http://dzil.org/ pour un tutoriel interactif ;
• Test::Reporter vous permet de générer le rapport des résultats des suites de tests automatisés pour les distributions que vous installez, fournissant à leurs auteurs plus de données sur les défaillances ;
• Carton et Pinto sont deux projets récents qui aident à gérer et installer les dépendances du code. Aucun n'est encore largement utilisé, mais ils sont tous deux en cours de développement actif.

Le processus de conception d'une distribution pourrait remplir un livre (voir Writing Perl Modules for CPAN de Sam Tregar), mais quelques principes de conception vous aideront. Commencez avec un utilitaire tel que Module::Starter ou Dist::Zilla. Le coût initial de l'apprentissage de la configuration et des règles peut sembler un investissement exagéré, mais l'avantage d'avoir tout mis en place de la bonne façon (et dans le cas de Dist::Zilla, ne jamais devenir obsolète) vous dispensera d'un travail fastidieux.

Une distribution devrait suivre plusieurs lignes directrices n'ayant pas à voir avec le code :

• chaque distribution effectue un seul but bien défini. Ce but peut même inclure plusieurs distributions connexes en les regroupant dans un seul paquet installable. Décomposez votre logiciel en distributions individuelles pour gérer correctement leurs dépendances et respecter leur encapsulation ;
• chaque distribution contient un numéro unique de version. Les numéros de version doivent toujours augmenter. La politique de « version sémantique » (http://semver.org/) à trois nombres (version majeure, version mineure, version corrective) est saine et compatible avec l'approche de Perl ;
• chaque distribution fournit une API bien définie. Une suite complète de tests automatisés peut vérifier si vous maintenez cette API entre les versions différentes. Si vous utilisez un miroir CPAN local pour installer vos propres distributions, vous pouvez réutiliser l'infrastructure CPAN pour tester les distributions et leurs dépendances. Vous obtenez facilement l'intégration en testant les composants réutilisables ;
• les tests de distribution sont utiles et reproductibles. L'infrastructure CPAN met en œuvre des rapports de test automatisés. Utilisez-les ! ;
• les interfaces sont simples et efficaces. Évitez l'utilisation des symboles globaux et les exports par défaut ; permettez aux gens d'utiliser uniquement ce dont ils ont besoin. Ne polluez pas leurs espaces de noms.

La méthode VERSION() retourne la valeur de la variable $VERSION du paquetage ou de la classe qui l'invoque. Si vous fournissez un numéro de version en tant que paramètre optionnel, la méthode lèvera une exception si la $VERSION interrogée n'est pas égale ou supérieure au paramètre.

Étant donné un module SingeHurleur de version 1.23 :

my $hm = SingeHurleur->new;

say SingeHurleur->VERSION;    # affiche 1.23
say $hm->VERSION;             # affiche 1.23
say $hm->VERSION( 0.0  );     # affiche 1.23
say $hm->VERSION( 1.23 );     # affiche 1.23
say $hm->VERSION( 2.0  );     # exception !

Il est très rarement utile de surcharger VERSION().

La méthode DOES() prend en charge l'utilisation des rôles (RôlesRôles) dans les programmes. Passez-lui un invoquant et le nom d'un rôle, et la méthode retournera la valeur vraie si la classe appropriée remplit ce rôle d'une façon ou d'une autre, que ce soit par héritage, délégation, composition, application de rôle, ou tout autre mécanisme.

La mise en œuvre par défaut de DOES() revient à isa(), parce que l'héritage est un mécanisme par lequel une classe peut remplir un rôle. Étant donné un Capucin :

say Capucin->DOES( 'Singe'      );  # prints 1
say $cappy->DOES(  'Singe'      );  # prints 1
say Capucin->DOES( 'Invertebre' );  # prints 0

Surchargez DOES() si vous consommez manuellement un rôle ou fournissez d'une quelconque façon une équivalence allomorphique.

La méthode can() accepte une chaîne contenant le nom d'une méthode. Elle retourne une référence vers la fonction qui implémente cette méthode, si elle existe. Sinon, elle retourne la valeur fausse. Vous pouvez l'appeler sur une classe, un objet, ou un nom d'un paquetage. Dans ce dernier cas, elle renvoie une référence de fonction et non de méthode... mais vous ne pouvez pas faire la différence, vu que ce n'est qu'une référence...

Étant donnée une classe nommée SingeAraignee ayant une méthode appelée crier, obtenez une référence à la méthode comme ceci :

if (my $methode = SingeAraignee->can( 'crier' )) {...}

Cette technique conduit au modèle de vérification de l'existence d'une méthode avant de l'appeler :

if (my $methode = $sm->can( 'crier' )
{
    # méthode; pas une fonction
    $sm->$methode();
}

Utilisez can() pour tester si un paquetage met en œuvre une fonction ou une méthode spécifique :

use Class::Load;

die "Impossible de charger $module!"
    unless load_class( $module );

if (my $enregistrer = $module->can( 'enregistrer' ))
{
    # fonction; pas une méthode
    $enregistrer->();
}

La méthode isa() reçoit une chaîne contenant le nom d'une classe ou le nom d'un type de base (SCALAR, ARRAY, HASH, Regexp, IO, et CODE). Appelez-la sur un objet comme une méthode de classe ou d'instance. isa() retourne la valeur vraie si son invoquant est ou dérive de la classe nommée, ou si l'invoquant est une référence liée au type donné.

Étant donné un objet $poivre (une référence de hachage liée à la classe Singe, qui hérite de la classe Mammifere) :

say $poivre->isa( 'Singe'    );  # affiche 1
say $poivre->isa( 'Mammifere');  # affiche 1
say $poivre->isa( 'HASH'     );  # affiche 1
say Singe->isa(   'Mammifere');  # affiche 1

say $poivre->isa( 'Dauphin'  );  # affiche 0
say $poivre->isa( 'ARRAY'    );  # affiche 0
say Singe->isa(   'HASH'     );  # affiche 0

Toute classe peut surcharger isa(). Cela peut être utile lorsque vous simulez des objets (voir Test::MockObject et Test::MockModule sur le CPAN) ou pour du code qui n'utilise pas les rôles (RôlesRôles). Sachez que toute classe qui redéfinit isa() doit généralement avoir une bonne raison pour le faire.

Il est tentant de stocker d'autres méthodes dans UNIVERSAL pour les rendre disponibles à tous les autres classes et objets Perl. Évitez cette tentation ; ce comportement global peut avoir des effets secondaires subtils, en particulier dans le code que vous n'avez pas écrit et ne maintenez pas, car il n'y a aucune contrainte.

Cela dit, l'abus occasionnel de UNIVERSAL à des fins de débogage et de correction des mauvais comportements par défaut peut être excusable. Par exemple, la distribution UNIVERSAL::ref de Joshua ben Jore rend utilisable l'opérateur quasi inutile ref(). Les distributions UNIVERSAL::can et UNIVERSAL::isa peuvent vous aider à déboguer des bogues en rapport avec le polymorphisme (L'équivalence méthode-fonctionL'équivalence méthode-fonction). Perl::Critic peut détecter ceux-ci et d'autres problèmes.

En dehors de bouts de code très soigneusement contrôlés et des situations très spécifiques, très pragmatiques, il n'y a aucune raison de mettre le code directement dans UNIVERSAL. Il y a presque toujours beaucoup de meilleurs choix de conception.

La technique de génération de code la plus simple est de construire une chaîne de caractères contenant un fragment de code Perl valide et de la compiler avec l'opérateur eval sur cette chaîne. À la différence de la forme eval de bloc, qui intercepte les exceptions, la forme eval de chaîne compile le contenu de la chaîne dans la portée courante, y compris le paquetage courant et les liaisons lexicales.

Une utilisation courante de cette technique fournit une solution de repli si vous ne pouvez pas (ou ne voulez pas) charger une dépendance optionnelle :

eval { require Singe::Traceur }
    or eval 'sub Singe::Traceur::log {}';

Si Singe::Traceur n'est pas disponible, ce code définit une fonction log() qui ne fera rien. Cet exemple simple est trompeur, parce qu'utiliser eval de façon correcte nécessite un peu de travail. Vous devez gérer des problèmes de guillemets lors de l'inclusion des variables au sein de votre code eval. Ajoutez plus de complexité pour interpoler certaines variables, mais pas d'autres :

sub generer_accesseurs
{
    my ($methname, $attrname) = @_;

    eval <<"END_ACCESSEUR";
    sub get_$methname
    {
        my \$self = shift;
        return \$self->{$attrname};
    }

    sub set_$methname
    {
        my (\$self, \$value) = \@_;
        \$self->{$attrname}  = \$value;
    }
END_ACCESSEUR
}

Malheur à ceux qui oublient un antislash ! Bonne chance pour convaincre votre coloration syntaxique de ce qui se passe ! Pire encore, chaque invocation de chaîne eval génère une nouvelle structure de données représentant l'ensemble du code. La compilation du code n'est pas gratuite non plus. Pourtant, même avec ses limites, cette technique est simple et utile.

Alors que la construction des accesseurs et mutateurs avec eval est simple, les fermetures (FermeturesFermetures) vous permettent d'ajouter des paramètres au code généré lors de la compilation sans nécessiter une évaluation supplémentaire :

sub generer_accesseurs
{
    my $attrname = shift;

    my $getter = sub
    {
        my $self = shift;
        return $self->{$attrname};
    };

    my $setter = sub
    {
        my ($self, $value) = @_;
        $self->{$attrname} = $value;
    };

    return $getter, $setter;
}

Ce code permet d'éviter les problèmes désagréables de guillemets et compile chaque fermeture une seule fois. Il utilise même moins de mémoire en partageant le code compilé entre toutes les instances de fermeture. Tout ce qui diffère est la liaison à la lexicale $attrname. Dans un processus de longue durée ou une classe avec beaucoup d'accesseurs, cette technique peut être très utile.

L'installation dans les tables de symboles est relativement facile, mais assez laide :

my ($get, $set) = generer_accesseurs( 'tarte' );

no strict 'refs';
*{ 'get_tarte' } = $get;
*{ 'set_tarte' } = $set;

Cette syntaxe bizarre d'astérisque (11), qui déréférence un hachage, renvoie à un symbole dans la table des symboles courante, qui est la section de l'espace de noms courant contenant des symboles globalement accessibles tels que des paquetages globaux, fonctions et méthodes. L'affectation d'une référence à une entrée de la table de symboles installe ou remplace cette entrée. Afin de promouvoir une fonction anonyme au rang de méthode, stockez la référence de cette fonction dans la table de symboles.

L'affectation d'une chaîne, et non d'une variable littérale, à un symbole de la table de symboles, est une référence symbolique. Vous devez désactiver la vérification des références de strict pour l'opération. De nombreux programmes ont un bogue subtil dans le code similaire, car ils font l'affectation et la génération de code en une seule ligne :

no strict 'refs';

*{ $methname } = sub {
    # bogue subtil : strict refs désactivé ici également
};

Cet exemple désactive strict pour le bloc externe ainsi que pour le corps de la fonction elle-même. Or, seule l'affectation viole la vérification stricte de référence, donc désactivez les restrictions pour cette seule opération :

{
    my $sub = sub { ... };

    no strict 'refs';
    *{ $methname } = $sub;
}

Si le nom de la méthode est une chaîne littérale dans votre code source, plutôt que le contenu d'une variable, vous pouvez l'attribuer directement au symbole pertinent :

{
    no warnings 'once';
    (*get_tarte, *set_tarte) =
         generer_accesseurs( 'pie' );
}

L'affectation directement à la glob ne viole pas les restrictions, mais mentionner chaque glob une seule fois fait produire un avertissement « used only once » que vous pouvez désactiver avec le pragma warnings.

À la différence du code écrit explicitement comme du code, le code généré par une chaîne eval sera compilé à l'exécution. De même, alors que vous pourriez vous attendre à ce qu'une fonction normale soit disponible pendant toute la durée de votre programme, une fonction générée dynamiquement pourrait ne pas être disponible quand vous vous y attendez.

Forcez Perl à exécuter ce code — pour générer un autre code — lors de la compilation en l'enveloppant dans un bloc BEGIN. Lorsque l'analyseur Perl rencontre un bloc étiqueté BEGIN, il analyse et compile l'ensemble du bloc, puis l'exécute (sauf s'il comporte des erreurs de syntaxe). Lorsque c'est terminé, la compilation continuera comme s'il n'y avait eu aucune interruption.

La différence entre :

sub get_age   { ... }
sub set_age   { ... }

sub get_nom   { ... }
sub set_nom   { ... }

sub get_poids { ... }
sub set_poids { ... }

... et :

sub creer_accesseurs { ... }

BEGIN
{
    for my $accesseur (qw( age nom poids ))
    {
        my ($get, $set) =
            creer_accesseurs( $accesseur );

        no strict 'refs';
        *{ 'get_' . $accesseur } = $get;
        *{ 'set_' . $accesseur } = $set;
    }
}

... est surtout une question de maintenabilité.

Dans un module, tout le code se trouvant en dehors de fonctions s'exécute lorsque vous appelez la fonction use pour charger le module, en raison de l'instruction implicite BEGIN que Perl ajoute autour du require et de l'import (ImportationImportation) exécutés par use. Tout code en dehors d'une fonction, mais à l'intérieur du module s'exécute avant que l'appel de import() ne se produise. Si en revanche vous utilisez require pour charger le module, il n'existe pas de bloc BEGIN implicite. Après la fin de la compilation du code du module, Perl exécutera le code en dehors des fonctions.

Méfiez-vous de l'interaction entre la déclaration lexicale (l'association d'un nom à une portée) et l'affectation lexicale. La première se produit lors de la compilation, tandis que la seconde a lieu à l'exécution. Ce code a un bogue subtil :

use UNIVERSAL::require;

# bogué; ne faites pas cela
my $package_voulu = 'Singe::Jetpack';

BEGIN
{
    $package_voulu->require;
    $package_voulu->import;
}

... car le bloc BEGIN s'exécutera avant que l'affectation de la valeur chaîne à $package_voulu ne se produise. Le résultat sera une exception à cause de la tentative d'appel de la méthode require()  (12) sur une valeur indéfinie.

À la différence de l'installation des références de fonction pour remplir des espaces de noms et créer des méthodes, il n'y a aucun moyen simple en Perl pour créer des classes à l'exécution. Moose vient à la rescousse, avec sa bibliothèque interne Class::MOP. Il fournit un protocole métaobjet — un mécanisme pour créer et manipuler un système objet en manipulant des objets.

Plutôt que d'écrire votre propre code fragile utilisant un eval de chaîne ou d'essayer de modifier manuellement des tables de symboles, vous pouvez manipuler les entités et les abstractions de votre programme par des objets et des méthodes.

Pour créer une classe :

use Class::MOP;

my $class = Class::MOP::Class->create(
                'Clef::Anglaise'
            );

Ajoutez des attributs et méthodes à la classe lorsque vous la créez :

my $class = Class::MOP::Class->create(
    'Clef::Anglaise' =>
    (
        attributes =>
        [
            Class::MOP::Attribute->new('$materiel'),
            Class::MOP::Attribute->new('$couleur'),
        ]
        methods =>
        {
            serrer    => sub { ... },
            desserrer => sub { ... },
        }
    ),
);

... ou à la métaclasse (l'objet qui représente cette classe) une fois créée :

$class->add_attribute(
    experience => Class::MOP::Attribute->new('$xp')
);

$class->add_method( bash_zombie => sub { ... } );

Vous pouvez inspecter la métaclasse :

my @attrs = $class->get_all_attributes;
my @meths = $class->get_all_methods;

De même Class::MOP::Attribute et Class::MOP::Method vous permettent la création, la manipulation et l'introspection des attributs et méthodes.

Le pragma overload associe des fonctions aux opérations susceptibles à être surchargées en passant des paires d'arguments, dont la clé est le nom d'un type de surcharge et la valeur est une référence de fonction. Une classe Null, qui surcharge l'évaluation booléenne de sorte qu'elle soit toujours évaluée à une valeur fausse, pourrait ressembler à ceci :

package Null
{
    use overload 'bool' => sub { 0 };

    ...
}

Il est facile d'ajouter une conversion en chaîne :

package Null
{
    use overload
        'bool' => sub { 0 },
        '""'   => sub { '(null)' };
}

La surcharge de la coercition numérique est plus complexe, car les opérateurs arithmétiques ont tendance à être opérateurs binaires (AritéArité). Dans le cas de deux opérandes, les deux ayant la méthode d'addition surchargée, quelle surcharge doit être prioritaire ? La réponse doit être cohérente, facile à expliquer, et compréhensible par les personnes qui n'ont pas lu le code source de l'application.

perldoc overload essaie d'expliquer cela dans les sections intitulées Calling Conventions for Binary Operations et MAGIC AUTOGENERATION, mais la solution la plus simple consiste à surcharger la conversion en nombre (en utilisant '0+') et de dire à overload d'utiliser les surcharges fournies comme des solutions de repli si possible :

package Null
{
    use overload
        'bool'   => sub { 0 },
        '""'     => sub { '(null)' },
        '0+'     => sub { 0 },
        fallback => 1;
    }

L'affectation d'une valeur vraie à fallback permet à Perl d'utiliser toute autre surcharge définie pour composer l'opération demandée lorsque c'est possible. Si ce n'est pas possible, Perl agira comme s'il n'y avait aucune surcharge en vigueur. C'est souvent ce que vous voulez.

Sans fallback, Perl utilisera uniquement les surcharges spécifiques que vous avez fournies. Si quelqu'un essaie d'effectuer une opération que vous n'avez pas surchargée, Perl signalera une exception.

Les sous-classes héritent des surcharges de leurs parentes. Elles peuvent redéfinir ce comportement de l'une des deux façons suivantes. Si la classe parente utilise la surcharge comme montré, avec des références de fonctions fournies directement, une classe enfant doit redéfinir le comportement surchargé du parent en utilisant directement overload.

Si vous écrivez une classe parente, utilisez un nom de méthode plutôt qu'une référence de fonction anonyme. Cela va permettre aux classes enfants de prouver leurs propres surcharges en redéfinissant les méthodes nommées :

package Null
{
    use overload
        'bool'   => 'get_bool',
        '""'     => 'get_string',
        '0+'     => 'get_num',
        fallback => 1;
}

Toute classe enfant peut faire quelque chose de différent pour la coercition booléenne, par exemple en surchargeant get_bool().

La surcharge peut sembler un outil tentant à utiliser pour produire des raccourcis symboliques de nouvelles opérations, mais c'est rarement pour une bonne raison. Le module IO::All du CPAN pousse cette idée à sa limite. En retour, vous obtenez une API simple et élégante. Pourtant, pour chaque API brillante affinée grâce à l'utilisation appropriée de la surcharge, une douzaine de problèmes surgissent. Parfois, le meilleur code évite l'habileté en faveur de la simplicité.

La redéfinition de l'addition, multiplication, et même concaténation sur une classe Matrice est logique, seulement parce que la notation existante pour ces opérations est omniprésente. Un nouveau domaine de problème sans une notation établie est un mauvais candidat à la surcharge, car c'est un domaine de problème où vous devez plisser les yeux pour faire les opérateurs existants de Perl correspondre à une notation différente.

Le livre De l'art de programmer en Perl de Damian Conway suggère une autre utilisation de la surcharge : pour éviter les abus accidentels d'objets. Par exemple, une surcharge de la conversion en nombre avec croak() pour des objets qui n'ont pas de représentation numérique unique raisonnable peut vous aider à trouver et à corriger les bogues réels.

Le mode taint attache une métadonnée adhésive à toutes les données qui viennent de l'extérieur de votre programme. Toutes les données obtenues à partir des données d'origine peu fiable sont également contaminées. Vous pouvez utiliser des données contaminées au sein de votre programme, mais si vous les utilisez pour influer sur le monde extérieur — si vous les utilisez de façon non sécurisée — Perl lancera une exception fatale.

perldoc perlsec explique le mode taint en grand détail.

Lancez votre programme avec l'argument de ligne de commande -T pour activer le mode taint. Si vous utilisez cet argument sur la ligne #! d'un programme, vous devez exécuter directement le nom du programme. Si vous l'exécutez avec perl mytaintedappl.pl et omettez l'option -T, Perl se terminera avec une exception — au moment où Perl rencontre l'option sur la ligne #!, il a raté sa chance de vérifier les données de l'environnement représenté par %ENV, par exemple.

La contamination peut provenir de deux sources : fichier d'entrée et environnement d'exploitation du programme. Le premier est ce que vous lisez à partir d'un fichier ou recevez de la part des utilisateurs dans le cas de la programmation Web ou un réseau. Le second comprend tous les arguments de ligne de commande, les variables d'environnement et des données provenant des appels système. Même les opérations telles que la lecture d'un descripteur de répertoire produisent des données contaminées.

La fonction tainted() du module standard Scalar::Util retourne vrai si son argument est contaminé :

die 'Oh non ! Données contaminées !'
    if Scalar::Util::tainted( $valeur_suspecte );

Pour décontaminer des données, vous devez en extraire certaines parties vérifiées avec des expressions régulières capturantes. Ces données capturées seront décontaminées.

Par exemple, si votre utilisateur doit saisir un numéro de téléphone américain, vous pouvez décontaminer la donnée obtenue avec :

die 'Numéro toujours contaminé !'
    unless $numero =~ /(\(/d{3}\) \d{3}-\d{4})/;

my $numero_verifie = $1;

Plus votre motif d'expression régulière est spécifique sur ce que vous autorisez, plus votre programme peut être sûr. L'approche inverse qui refuse certains éléments ou formes spécifiques court le risque de négliger quelque chose de dangereux. Mieux vaut interdire quelque chose de sûr, mais inattendu, que d'accepter quelque chose de nocif qui paraît sûr. Pourtant, rien ne vous empêche d'écrire un motif capturant la totalité du contenu d'une variable, mais, dans ce cas, pourquoi utiliser le mode taint ?

La variable superglobale %ENV représente les variables d'environnement du système. Ces données sont contaminées parce que des forces qui échappent au contrôle du programme peuvent y manipuler des valeurs. Toute variable d'environnement qui modifie la façon dont Perl ou le shell trouvent des fichiers et des répertoires est un vecteur d'attaque. Un programme sensible à contamination devrait supprimer plusieurs clés de %ENV et définir $ENV{PATH} à un chemin spécifique et bien sécurisé :

delete @ENV{ qw( IFS CDPATH ENV BASH_ENV ) };
$ENV{PATH} = '/path/to/app/binaries/';

Si vous ne définissez pas correctement $ENV{PATH}, vous recevrez des messages sur son insécurité. Si cette variable d'environnement contenait le répertoire de travail courant, ou si elle contenait des répertoires relatifs, ou si les répertoires spécifiés avaient des autorisations d'écriture à tout le monde, un attaquant ingénieux pourrait détourner les appels système pour commettre des méfaits.

Pour des raisons similaires, @INC ne contient pas le répertoire de travail courant en mode taint. Perl ignorera également les variables d'environnement PERL5LIB et PERLLIB. Utilisez le pragma lib ou l'option -I de la ligne de commande perl pour ajouter des répertoires de bibliothèques au programme.

Le mode taint est tout ou rien. Il est soit actif, soit inactif. Cela amène parfois les gens à utiliser des motifs permissifs pour décontaminer des données, et donne l'illusion de sécurité. Dans ce cas, le mode taint n'offre aucune sécurité réelle. Examinez attentivement vos règles de décontamination.

Malheureusement, tous les modules ne traitent pas les données contaminées de façon appropriée. C'est un bogue que les auteurs du CPAN devraient prendre au sérieux. Si vous devez sécuriser du code hérité, envisagez l'utilisation de l'option -t, qui active le mode taint, mais fait passer les violations du mode taint du rang d'erreurs fatales à celui de simples avertissements. Ce n'est pas une solution de rechange au substitut pour le mode taint complet, mais il vous permet de sécuriser les programmes existants sans l'approche tout ou rien de -T.