Perl moderne : 2014

L'aplatissement de liste en @_ se passe du côté appelant d'un appel de fonction. Le passage d'un hachage comme argument produit une liste de paires clé/valeur :

my %animaux_noms_et_types = (
    Lucky   => 'chien',
    Rodney  => 'chien',
    Tuxedo  => 'chat',
    Petunia => 'chat',
    Rosie   => 'chien',
);

afficher_animaux( %animaux_noms_et_types );

sub afficher_animaux
{
    my %animaux = @_;
    while (my ($nom, $type) = each %animaux)
    {
        say "$nom est un $type";
    }
}

Lorsque Perl aplatit %animaux_noms_et_types dans une liste, l'ordre des paires clé/valeur du hachage varie, mais la liste contiendra toujours une clé suivie immédiatement par sa valeur. L'affectation du hachage à l'intérieur de afficher_animaux() fonctionne de la même manière que l'affectation explicite à %animaux_noms_et_types.

Cet aplatissement est souvent utile, mais évitez de mélanger des scalaires et des variables composites aplaties en listes de paramètres. Pour écrire une fonction afficher_animaux_par_type() où l'un des paramètres est le type d'animal de compagnie à afficher, passez le type comme premier paramètre (ou utilisez pop pour le supprimer de la fin de @_, si vous aimez dérouter les gens) :

sub afficher_animaux_par_type
{
    my ($type, %animaux) = @_;

    while (my ($nom, $espece) = each %animaux)
    {
        next unless $espece eq $type;
        say "$nom est un $espece";
    }
}

my %animaux_noms_et_types = (
    Lucky   => 'chien',
    Rodney  => 'chien',
    Tuxedo  => 'chat',
    Petunia => 'chat',
    Rosie   => 'chien',
);

afficher_animaux_par_type( 'chien',   %animaux_noms_et_types );
afficher_animaux_par_type( 'chat',    %animaux_noms_et_types );
afficher_animaux_par_type( 'orignal', %animaux_noms_et_types );

L'affectation de liste d'une variable agrégée est toujours gourmande, donc l'affectation à %animaux absorbe (slurps) toutes les valeurs restantes de @_. Si le paramètre $type se trouve à la fin de @_, Perl émettrait un avertissement sur l'affectation d'un nombre impair d'éléments au hachage. Vous pourriez contourner cela :

sub afficher_animaux_par_type
{
    my $type    = pop;
    my %animaux = @_;

    ...
}

... au détriment de la clarté. Le même principe s'applique lors de l'affectation d'un tableau comme paramètre. Utilisez des références (RéférencesRéférences) pour éviter l'aplatissement global indésirable.

Le tableau @_ contient une subtilité : il crée des alias sur les arguments des fonctions. Autrement dit, vous pouvez modifier les arguments passés à la fonction si vous accédez directement à @_ :

sub modifier_nom
{
    $_[0] = reverse $_[0];
}

my $nom = 'Orange';
modifier_nom( $nom );
say $nom;

# affiche egnarO

Modifiez directement un élément de @_ et vous allez modifier l'argument initial. Soyez prudent et déballez le contenu de @_ rigoureusement ou documentez soigneusement la modification.

Lors du chargement d'un module avec la commande interne use (ModulesModules), Perl appelle automatiquement une méthode nommée import(). Les modules peuvent fournir leur propre méthode import(), ce qui rend disponibles dans le paquetage appelant tous les symboles définis ou une partie de ceux-ci. Les arguments qui suivent le nom du module dans l'instruction use sont transmis à la méthode import() du module. Ainsi :

use strict;

... charge le module strict.pm et appelle strict->import() sans arguments, tandis que :

use strict 'refs';
use strict qw( subs vars );

... charge le module strict.pm, appelle strict->import( 'refs' ), puis appelle strict->import('subs', vars ').

use a un comportement particulier en ce qui concerne import(), mais vous pouvez appeler import() directement. L'exemple use ci-dessus est équivalent à :

BEGIN
{
    require strict;
    strict->import( 'refs' );
    strict->import( qw( subs vars ) );
}

La commande interne use ajoute un bloc implicite BEGIN autour de ces déclarations afin que l'appel de import() ait lieu immédiatement après que l'analyseur a compilé toute l'instruction use. Cela garantit que l'analyseur connaît tous les symboles importés par strict avant de compiler le reste du programme. Dans le cas contraire, toute fonction importée d'un autre module, mais non déclarée dans le fichier courant ressemblerait à un « mot nu » et enfreindrait strict, par exemple.

Bien sûr, strict est un pragma (PragmasPragmas), alors il a d'autres effets.

Tout en faisant de son mieux pour faire ce que vous lui demandez, Perl offre quelques façons natives de tester la validité des arguments fournis à une fonction. Évaluez @_ en contexte scalaire pour vérifier si le nombre de paramètres passés à une fonction est correct :

sub ajouter_nombres
{
    croak 'Attendait deux nombres, a reçu : ' . @_
        unless @_ == 2;

    ...
}

Cette validation signale toute erreur concernant le nombre de paramètres du point de vue de l'appelant, grâce à l'utilisation de croak.

La vérification du type est plus difficile, en raison des conversions de type effectuées par les opérateurs de Perl (ContexteContexte). Si vous voulez une sécurité supplémentaire des paramètres de la fonction, regardez les modules CPAN tels que Params::Validate ou MooseX::Method::Signatures.

Les fonctions internes de Perl savent si vous les avez invoquées dans un contexte vide, scalaire ou de liste. Vos fonctions peuvent aussi le savoir. La fonction interne malnommée wantarray (voir perldoc -f wantarray) retourne undef pour signaler le contexte vide, une valeur fausse pour signaler un contexte scalaire et une valeur vraie pour signaler un contexte de liste.

sub sensible_au_contexte
{
    my $contexte = wantarray();

    return qw( Contexte de liste ) if         $contexte;
    say    'Contexte vide'     unless defined $contexte;
    return 'Contexte scalaire' unless         $contexte;
}

sensible_au_contexte();
say my $scalaire = sensible_au_contexte();
say sensible_au_contexte();

Cela peut être utile pour éviter que des fonctions qui pourraient produire des valeurs de retour coûteuses le fassent dans un contexte vide. Certaines fonctions idiomatiques retournent une liste dans un contexte de liste et le premier élément de la liste ou une référence de tableau dans un contexte scalaire. Rappelez-vous, cependant, qu'il n'existe pas d'unique meilleure recommandation pour l'utilisation de wantarray. Parfois, c'est plus clair d'écrire des fonctions distinctes et sans ambiguïté, comme trouver_garnitures_toutes() et trouver_garniture_suivante().

Supposons que vous voulez trouver un élément dans un tableau trié. Vous pouvez itérer sur chaque élément du tableau individuellement à la recherche de la cible, mais vous aurez à examiner en moyenne la moitié des éléments du tableau. Une autre approche consiste à diviser le tableau en deux, choisir l'élément du milieu, comparer, puis répéter l'opération avec la moitié inférieure ou supérieure selon le résultat de la comparaison. Diviser pour régner. Lorsque vous épuisez les éléments à inspecter ou vous trouvez l'élément, arrêter.

Un test automatisé pour cette technique pourrait être :

use Test::More;

my @elements =
(
    1, 5, 6, 19, 48, 77, 997, 1025, 7777, 8192, 9999
);

ok   elem_existe(     1, @elements ),
        'trouvé le premier élément du tableau';
ok   elem_existe(  9999, @elements ),
        'trouvé le dernier élément du tableau';
ok ! elem_existe(   998, @elements ),
       'pas trouvé, élément absent du tableau';
ok ! elem_existe(    -1, @elements ),
       'pas trouvé, élément absent du tableau';
ok ! elem_existe( 10000, @elements ),
       'pas trouvé, élément absent du tableau';

ok   elem_existe(    77, @elements ),
       'trouvé élément du milieu du tableau';
ok   elem_existe(    48, @elements ),
       'trouvé la fin de la moitié inférieure du tableau';
ok   elem_existe(   997, @elements ),
        'trouvé le début de la moitié supérieure du tableau';

done_testing();

La récursivité est un concept d'une simplicité trompeuse. Chaque appel à une fonction en Perl crée un nouveau contexte d'appel (call frame), une structure de données interne à Perl qui représente le fait d'avoir appelé une fonction. Il contient l'environnement lexical de l'invocation actuelle — les valeurs de toutes les variables lexicales au sein de la fonction invoquée. Le stockage des valeurs des variables lexicales étant séparé de la fonction elle-même, vous pouvez avoir plusieurs appels actifs à une fonction en même temps. Une fonction peut même s'appeler elle-même, récursivement.

Pour passer le test précédent, écrivons la fonction récursive elem_existe() ainsi :

sub elem_existe
{
    my ($item, @array) = @_;

    # arrêter la recherche récursive si pas d'élément à rechercher
    return unless @array;

    # descendre d'un demi-cran en cas d'un nombre pair d'éléments
    my $milieu = int( (@array / 2) - 0.5 );
    my $element_milieu = $array[ $milieu ];

    # retourner vrai si l'élément a été trouvé
    return 1 if $item  == $element_milieu;

    # retourner faux si un seul élément dans le tableau
    return   if @array == 1;

    # recherche récursive dans la moitié inférieure du tableau
    return elem_existe(
        $item, @array[0 .. $milieu]
    ) if $item < $element_milieu;

    # recherche récursive dans la moitié supérieure du tableau
    return elem_existe(
         $item, @array[ $milieu + 1 .. $#array ]
    );
}

Gardez à l'esprit que les arguments de la fonction seront différents pour chaque appel, sinon la fonction se comporterait toujours de la même façon (elle continuera la récursion jusqu'à ce que le programme plante). C'est pour cela que la condition d'arrêt est si importante.

Tout programme récursif peut être écrit sans récursivité (voir le livre Higher Order Perl à http://hop.perl.plover.com/), mais cette approche consistant à diviser pour régner est un moyen efficace de gérer de nombreux types de problèmes similaires.

Comme impliqué par la récursivité, chaque appel d'une fonction crée sa propre instance de portée lexicale représentée en interne par un contexte d'appel. Même si la déclaration de elem_existe() crée une seule portée pour les lexicales $item, @array, $midpoint et $miditem, chaque appel à elem_existe() — même récursif — stocke les valeurs de ces variables lexicales séparément.

Non seulement elem_existe() peut s’appeler elle-même, mais les variables lexicales de chaque appel sont protégées et séparées :

use Carp 'cluck';

sub elem_existe
{
    my ($item, @array) = @_;

    cluck "[$item] (@array)";
    ...
}

Un inconvénient de la récursivité est que vous devez gérer correctement les valeurs de retour, faute de quoi votre fonction risque de s’appeler indéfiniment. Pour cette raison, la fonction elem_existe() a plusieurs instructions return. Perl offre un avertissement utile Deep recursion on subroutine lorsqu'il soupçonne une récursivité incontrôlée. La limite fixée à 100 appels récursifs est arbitraire, mais souvent utile. Vous pouvez désactiver cet avertissement avec no warnings 'recursion'.

Comme chaque appel à une fonction nécessite un nouveau contexte d'appel et de l'espace de stockage lexical, le code hautement récursif peut utiliser plus de mémoire que le code itératif. L'élimination des récursions terminales peut aider.

Une récursion terminale est un appel à une fonction qui retourne directement les résultats de cette fonction. Ces appels récursifs à elem_existe() :

# recherche récursive dans la moitié inférieure du tableau
return elem_existe(
    $item, @array[0 .. $milieu]
) if $item < $element_milieu;

# recherche récursive dans la moitié supérieure du tableau
return elem_existe(
     $item, @array[ $milieu + 1 .. $#array ]
);

... sont candidats à l'élimination de la récursion terminale. Cette optimisation éviterait de retourner à l'appel courant, puis à l'appel parent et ainsi de suite. Au lieu de cela, elle retourne directement à l'appel parent d'origine.

Perl n'élimine pas automatiquement les récursions terminales, mais vous pouvez obtenir le même effet en utilisant une forme particulière de la fonction goto. Contrairement à la forme qui produit souvent du code nommé spaghetti (parce que le flot d'exécution est aussi simple et direct qu'un plat de spaghettis), cette forme de la fonction goto remplace l'appel de fonction en cours par l'appel à une autre fonction. Vous pouvez utiliser une fonction par nom ou par référence. Vous pouvez même modifier les arguments passés à la fonction de remplacement en modifiant @_ :

# recherche récursive dans la moitié inférieure du tableau
if ($item < $element_milieu)
{
    @_ = ($item, @array[0 .. $milieu]);
    goto &elem_existe;
}

# recherche récursive dans la moitié supérieure du tableau
else
{
    @_ = ($item, @array[$milieu + 1 .. $#array] );
    goto &elem_existe;
}

Les optimisations sont parfois laides, mais si l'autre option est un code hautement récursif qui épuise la mémoire, choisissez la laideur et profitez de son côté pratique.

La portée lexicale est la portée visible pour vous quand vous lisez un programme. Un bloc délimité par des accolades — que ce soit un bloc nu, le bloc d'une boucle ou d'une déclaration sub, un bloc eval, un bloc package ou tout bloc autre que ceux associés aux opérateurs de citation — crée une nouvelle portée. Le compilateur Perl résout cette portée pendant la compilation.

La portée lexicale décrit la visibilité des variables déclarées avec my — les variables lexicales. Une variable lexicale déclarée à l'intérieur d'une portée est visible dans cette portée et toutes les portées imbriquées intérieures, mais est invisible dans les portées sœurs ou dans les portées extérieures :

# portée lexicale extérieure
{
    package Robot::Butler

    # portée lexicale intérieure
    my $niveau_batterie;

    sub chambre_propre
    {
        # une autre portée lexicale plus intérieure
        my $minuteur;

        do {
            # la portée lexicale la plus intérieure 
            my $ramassette;
            ...
        } while (@_);

        # la sœur de l'autre portée lexicale plus intérieure
        for (@_)
        {
            # une portée lexicale plus intérieure séparée 
            my $chiffon;
            ...
        }
    }
}

... $niveau_batterie est visible dans les quatre portées. $minuteur est visible dans la méthode, le bloc do et la boucle for. $ramassette n'est visible que dans le bloc do et $chiffon uniquement dans la boucle for.

La déclaration dans une portée interne d'une variable lexicale du même nom que celui d'une variable lexicale déclarée dans une portée externe cache, ou occulte, la variable lexicale externe dans la portée interne.

Par exemple :

my $nom = 'Jacob';

{
    my $nom = 'Edward';
    say $nom;
}

say $nom;

Dans du code plus long avec des portées plus étendues, ce comportement d'occultation est souvent souhaitable — il est plus facile de comprendre le code lorsque la portée d'une variable lexicale n'est pas plus étendue que quelques dizaines de lignes.

Le petit exemple de programme d'occultation lexicale affiche Edward, puis Jacob parce que la variable lexicale dans la portée interne cache la variable lexicale dans la portée externe. L'occultation d'une variable lexicale est une caractéristique de l'encapsulation. La déclaration de plusieurs variables ayant le même nom et le même type dans la même portée lexicale produit un message d'avertissement.

Certaines déclarations lexicales ont des subtilités, par exemple une variable lexicale utilisée comme variable d'itération d'une boucle for. Sa déclaration se trouve en dehors du bloc, mais sa portée est à l'intérieur du bloc de la boucle :

my $chat = 'Brad';

for my $chat (qw( Jack Daisy Petunia Tuxedo Choco ))
{
    say "Le chat de l'itération est $chat";
}

say "Le chat statique est $chat";

Les fonctions — nommés et anonymes — fournissent une portée lexicale à leur corps. Cela permet les fermetures (FermeturesFermetures).

À l'intérieur d'une portée donnée, déclarez un alias pointant vers une variable de paquetage avec la fonction our. Comme my, our applique la portée lexicale de l'alias. Le nom complet est disponible partout, mais l'alias lexical n'est visible qu'à l'intérieur de sa portée.

our est surtout utile avec des variables globales de paquetage comme $VERSION et $AUTOLOAD. Vous obtenez un peu de détection typographique (la déclaration d'un paquetage global avec our satisfait la règle vars du pragma strict), mais vous avez toujours affaire à une variable globale.

La portée dynamique ressemble à la portée lexicale en matière de règles de visibilité, mais au lieu de regarder vers l'extérieur dans les portées de compilation, la recherche va en arrière à travers tous les appels de fonction que vous avez faits pour atteindre le code actuel. La portée dynamique s'applique uniquement aux variables globales et variables globales de paquetage (parce que les variables lexicales ne sont pas visibles en dehors de leur portée) et est plus facile à comprendre avec un exemple. Alors qu'une variable globale de paquetage peut être visible à l'intérieur de toutes les portées, sa valeur peut changer en fonction de la localisation et de l'affectation :

our $portee;

sub interne
{
     say $portee;
}

sub main
{
    say $portee;
    local $portee = 'portée main()';
    milieu();
}

sub milieu
{
    say $portee;
    interne();
}

$portee = 'portée externe';
main();
say $portee;

Le programme commence par déclarer une variable our, $portee, ainsi que trois fonctions. Il se termine par l'initialisation de $portee et l'appel à main().

Dans main(), le programme affiche la valeur actuelle de $portee, portée externe, puis localise la variable. Cela modifie la visibilité du symbole dans la portée lexicale courante ainsi que dans toutes les fonctions appelées à partir de la portée lexicale courante ; c'est cet « ainsi que »qui distingue la portée dynamique de la portée statique. Donc, $portee contient portée main() à la fois dans le corps de milieu() et interne(). Après le retour de main(), lorsque le flot d'exécution atteint la fin de son bloc, Perl restaure la valeur d'origine de $portee qui avait été provisoirement localisée. La dernière instruction say affiche une fois de plus portée externe.

Perl utilise des règles de visibilité et mécanismes de stockage différents pour les variables de paquetage et les variables lexicales. Chaque portée qui contient des variables lexicales utilise une structure de données appelée carnet lexical ou lexpad pour stocker les valeurs des variables lexicales incluses. Chaque fois que le flot d'exécution entre dans l'une de ces portées, Perl crée un autre carnet lexical pour contenir les valeurs des variables lexicales pour cet appel en particulier. Cela fait que les fonctions travaillent correctement, en particulier lors des appels récursifs (RécursivitéRécursivité).

Chaque paquetage a une table de symboles unique qui contient les variables de paquetage ainsi que les fonctions nommées. L'importation (ImportationImportation) fonctionne par l'inspection et la manipulation de cette table de symboles. Il en va de même pour local. Vous pouvez localiser uniquement des variables globales et variables globales de paquetage, jamais des variables lexicales.

local est le plus souvent utile avec des variables magiques. Par exemple, $/, le séparateur d'enregistrements en entrée, définit la quantité de données qu'une opération readline lira à partir d'un descripteur de fichier. $!, la variable d'erreur système, contient des détails d'erreur pour le dernier appel système. $@, la variable Perl d'erreur de eval, contient les erreurs de l'opération eval la plus récente. $|, la variable d'écriture immédiate (autoflush) des tampons attachés au descripteur de fichier, détermine si Perl écrit immédiatement dans le descripteur de fichier sélectionné après chaque opération d'écriture.

La localisation de ceux-ci dans la portée la plus étroite possible limite l'effet de vos modifications. Cela peut éviter des comportements étranges ailleurs dans votre code.

Perl 5.10 a ajouté une nouvelle portée pour prendre en charge la commande interne state. La portée d'état ressemble à la portée lexicale en matière de visibilité, mais ajoute une initialisation ainsi que la persistance de la valeur :

sub compteur
{
    state $total = 1;
    return $total++;
}

say compteur();
say compteur();
say compteur();

Lors du premier appel à compteur, Perl initialise $total. Lors des prochains appels, $total conserve sa valeur précédente. Ce programme imprime 1, 2 et 3. Remplacez state par my et le programme affichera 1, 1 et 1.

Vous pouvez utiliser une expression pour définir la valeur initiale d'une variable state :

sub  compteur
{
    state $total = shift;
    return $total++;
}

say compteur(2);
say compteur(4);
say compteur(6);

Même si une simple lecture du code peut suggérer que la sortie devrait être 2, 4 et 6, elle est en fait 2, 3 et 4. Le premier appel de compteur initialise la variable $total. Les appels suivants ne changeront pas sa valeur.

state peut être utile pour définir une valeur par défaut ou préparer un cache, mais assurez-vous de comprendre son comportement d'initialisation si vous l'utilisez :

sub compteur
{
    state $total = shift;
    say 'Second arg est : ', shift;
    return $total++;
}

say counter(2, 'deux'  );
say counter(4, 'quatre');
say counter(6, 'six'   );

Le compteur de ce programme imprime 2, 3, et 4 comme prévu, mais les valeurs des seconds arguments destinés à compteur() sont deux, 4 et 6 — parce que le shift du premier argument ne se produit que dans le premier appel de compteur(). Soit changez l'interface pour éviter cette erreur, soit écrivez ceci :

sub compteur
{
    my ($valeur_initiale, $texte) = @_;

    state $total = $valeur_initiale;
    say "Second arg est : $texte";
    return $total++;
}

say compteur(2, 'deux'  );
say compteur(4, 'quatre');
say compteur(6, 'six'   );

L'utilisation de l'instruction sub sans aucun nom crée et retourne une fonction anonyme. Utilisez cette référence de fonction à n'importe quel endroit où vous utiliseriez une référence vers une fonction nommée, comme pour déclarer les fonctions directement dans une table de distribution :

my %calculer =
(
    plus      => sub { $_[0]  + $_[1] },
    moins     => sub { $_[0]  - $_[1] },
    fois      => sub { $_[0]  * $_[1] },
    diviser   => sub { $_[0]  / $_[1] },
    puissance => sub { $_[0] ** $_[1] },
);

Vous pouvez voir également des fonctions anonymes passées comme arguments de fonction :

sub invoquer_fonction_anonyme
{
    my $func = shift;
    return $func->( @_ );
}

sub fonction_nommee
{
    say 'Je suis une fonction nommée !';
}

invoquer_fonction_anonyme( \&fonction_nommee );
invoquer_fonction_anonyme( sub { say 'qui suis-je ?' } );

Utilisez l'introspection (voir aussi la fonction sub_name du module CPAN Sub::Identify) pour déterminer si une fonction est nommée ou anonyme :

package ShowCaller;

sub afficher_appelant
{
    my ($paquetage, $fichier, $ligne, $fonction) = caller(1);
    say "Appelée par $fonction à $paquetage:$fichier:$ligne";
}

sub main
{
    my $sub_anonyme = sub { afficher_appelant() };
    afficher_appelant();
    $sub_anonyme->();
}

main();

Le résultat peut être surprenant :

La __ANON__ sur la deuxième ligne de la sortie montre que la fonction anonyme n'a aucun nom que Perl puisse identifier. Cela peut compliquer le débogage. La fonction subname() du module CPAN Sub::Name vous permet d'attacher des noms aux fonctions anonymes :

use Sub::Name;
use Sub::Identify 'sub_nom';

my $anonyme  = sub {};
say sub_nom( $anonyme );

my $nommee = subname( 'pseudo-anonyme', $anonyme );
say sub_nom( $nommee  );
say sub_nom( $anonyme );

say sub_nom( sub {}   );

Ce programme affiche en sortie :

Sachez que les deux références désignent la même fonction anonyme sous-jacente. L'utilisation de subname() sur une référence de fonction modifiera le nom de cette fonction anonyme, de sorte que toutes les autres références vers elle verront le nouveau nom.

Perl vous permet de déclarer des fonctions anonymes comme arguments d'une fonction sans utiliser le mot-clé sub. Bien que cette fonctionnalité existe nominalement pour permettre aux programmeurs d'écrire leur propre syntaxe comme celle pour map et eval (PrototypesPrototypes), un exemple intéressant est l'utilisation des fonctions qui ne ressemblent pas à des fonctions. Ce n'est pas parfait, mais peut rendre le code plus facile à lire.

Examinons le module Test::Fatal du CPAN, qui prend une fonction anonyme comme premier argument de sa fonction exception() :

use Test::More;
use Test::Fatal;

my $croaker = exception { die 'I croak!' };
my $liver   = exception { 1 + 1 };

like( $croaker, qr/I croak/, 'die() should croak'   );
is(   $liver,   undef,       'addition should live' );

done_testing();

Vous pourriez réécrire cela de façon plus explicite :

my $croaker = exception( sub { die 'I croak!' } );
my $liver   = exception( sub { 1 + 1 } );

... ou passer par référence des fonctions nommées :

sub croaker { die 'I croak!' }
sub liver   { 1 + 1 }

my $croaker = exception \&croaker;
my $liver   = exception \&liver;

like( $croaker, qr/I croak/, 'die() should die'     );
is(   $liver,   undef,       'addition should live' );

... mais vous ne pouvez pas les passer comme des références scalaires :

my $croak_ref = \&croaker;
my $live_ref  = \&liver;

# BOGUE: ne fonctionne pas
my $croaker   = exception $croak_ref;
my $liver     = exception $live_ref;

... parce que le prototype change la façon dont l'analyseur Perl interprète ce code. Il ne peut pas déterminer avec 100 % de clarté que contiendront $croaker et $liver et lèvera une exception.

Sachez également qu'une fonction qui accepte une fonction anonyme comme le premier de plusieurs arguments ne peut pas avoir une virgule de fin après le bloc de fonction :

use Test::More;
use Test::Fatal 'dies_ok';

dies_ok { die 'This is my boomstick!' }
        'No movie references here';

C'est un inconvénient parfois déroutant de la syntaxe autrement utile, à cause d'une bizarrerie de l'analyseur Perl. La clarté syntaxique disponible en favorisant des blocs nus dans les fonctions anonymes peut être utile, mais utilisez-la avec parcimonie et documentez l'API avec soin.

Une fermeture est une fonction qui utilise les variables lexicales d'une portée externe. Vous avez probablement déjà créé et utilisé des fermetures sans vous en rendre compte :

use Modern::Perl '2014';

my $nom_fichier = shift @ARGV;

sub get_nom_fichier { return $nom_fichier }

Si ce code vous semble simple, tant mieux ! Bien sûr, la fonction get_nom_fichier() peut voir la variable lexicale $nom_fichier. C'est ainsi que la portée fonctionne !

Supposons que vous vouliez parcourir une liste d'éléments sans avoir à gérer vous-même la variable d'itération. Vous pouvez créer une fonction qui retourne une fonction qui, une fois invoquée, retournera l'élément suivant dans l'itération :

sub creer_iterateur
{
    my @elements = @_;
    my $compteur = 0;

    return sub
    {
        return if $compteur == @elements;
        return $elements[ $compteur++ ];
    }
}

my $cousins = creer_iterateur(qw(
    Rick Alex Kay Eric Corey Mandy Christine Alex
));

say $cousins->() for 1 .. 6;

Même si le retour de creer_iterateur() a eu lieu, la fonction anonyme stockée dans $cousins « s'est fermée » sur les valeurs de ces variables telles qu'elles existaient au sein de l'invocation de creer_iterateur(). Leurs valeurs persistent (Comptage des référencesComptage des références).

Parce que l'appel de creer_iterateur() crée un environnement lexical distinct, la fonction anonyme qu'il crée et retourne se referme un environnement lexical unique pour chaque appel :

my $tantes = creer_iterateur(qw(
    Carole Phyllis Wendy Sylvia Monica Lupe
));

say $cousins->();
say $tantes->();

Comme creer_iterateur() ne retourne pas ces variables lexicales par valeur ou par référence, aucun code Perl autre que la fermeture ne peut y accéder. Elles sont encapsulées aussi efficacement que n'importe quelle autre lexicale, bien que n'importe quel code qui partage un environnement lexical puisse accéder à ces valeurs. Cet idiome offre une meilleure encapsulation de ce qui serait par ailleurs une variable globale à un fichier ou à un paquetage :

{
    my $variable_privee;

    sub set_privee { $variable_privee = shift }
    sub get_privee { $variable_privee }
}

Sachez que vous ne pouvez pas imbriquer des fonctions nommées. Les fonctions nommées ont une portée globale de paquetage. Toutes les variables lexicales partagées entre les fonctions imbriquées ne le seront plus lorsque la fonction externe détruit son premier environnement lexical. Si cela vous semble confus, imaginez la mise en œuvre.

L'itération sur une liste de taille fixe avec une fermeture est intéressante, mais les fermetures peuvent faire beaucoup plus, comme itérer sur une liste qui est trop coûteuse à calculer ou trop grande pour la garder intégralement en mémoire. Considérons une fonction pour créer des suites de Fibonacci au fur et à mesure que vous avez besoin de ses éléments. Pour quoi faire ? Pour vérifier vos devoirs en langage de programmation Haskell. Au lieu de recalculer la série de manière récursive, utilisez un cache et créez paresseusement les éléments dont vous avez besoin :

sub gen_fib
{
    my @fibs = (0, 1);
    return sub
    {
        my $element = shift;
        if ($element >= @fibs)
        {
            for my $calc (@fibs .. $element)
            {
                $fibs[$calc] = $fibs[$calc - 2]
                             + $fibs[$calc - 1];
            }
        }
        return $fibs[$element];
    }
}

# calculer le quarante-deuxième nombre Fibonacci 
my $fib = gen_fib();
say $fib->( 42 );

Chaque appel à la fonction retournée par gen_fib() prend un seul argument, le nième élément de la série de Fibonacci. La fonction génère et met en cache toutes les valeurs précédentes dans la série comme nécessaire, et renvoie l'élément demandé.

Voici où les fermetures et les fonctions de première classe deviennent intéressantes. Ce code fait deux choses ; il existe un modèle spécifique de mise en cache étroitement lié à la série numérique. Qu'advient-il si vous extrayez le code de cache spécifique (initialiser un cache, exécuter le code personnalisé pour charger en cache les éléments et retourner la valeur calculée ou mise en cache) à une fonction gen_caching_closure() ?

sub gen_caching_closure
{
    my ($calc_element, @cache) = @_;
    return sub
    {
        my $element = shift;
        $calc_element->($element, \@cache)
            unless $element < @cache;
        return $cache[$element];
    };
}

sub gen_fib
{
    my @fibs = (0, 1, 1);
    return gen_caching_closure( sub
        {
            my ($element, $fibs) = @_;
            for my $calc ((@$fibs - 1) .. $element)
            {
                $fibs->[$calc] = $fibs->[$calc - 2]
                               + $fibs->[$calc - 1];
            }
        }, @fibs
    );
}

Le programme se comporte comme précédemment, mais maintenant les références de fonction et les fermetures séparent le comportement d'initialisation de cache du calcul du prochain nombre de la suite de Fibonacci. La personnalisation du comportement du code — dans ce cas, gen_caching_closure() — en passant en argument une fonction permet une grande flexibilité et peut nettoyer votre code.

Les fermetures peuvent également supprimer la généricité non désirée. Prenons le cas d'une fonction qui accepte plusieurs paramètres :

sub preparer_coupe_glace
{
    my %args         = @_;

    my $creme_glacee = get_creme_glacee( $args{creme_glacee} );
    my $banane       = get_banane(       $args{banane}       );
    my $sirop        = get_sirop(        $args{sirop}        );
    ...
}

Les multiples possibilités de personnalisation pourraient fonctionner très bien dans une glacerie, mais pour un triporteur pour vente ambulante de glaces où vous servez seulement de la glace française à la vanille sur banane Cavendish, chaque appel à preparer_coupe_glace() passe toujours les mêmes arguments.

Une application partielle vous permet de lier maintenant certains des arguments à une fonction afin que vous puissiez fournir les autres plus tard. Enveloppez dans une fermeture la fonction que vous souhaitez appeler et passez les arguments liés. Pour votre triporteur de glaces :

my $preparer_coupe_triporteur = sub
{
    return preparer_coupe_glace( @_,
        creme_glacee => 'Vanille française',
        banane       => 'Cavendish',
    );
};

Maintenant, chaque fois que vous traitez une commande, invoquez la référence de fonction $preparer_coupe_triporteur et passez uniquement les arguments intéressants.(6) Vous n'allez jamais oublier ou transmettre de manière incorrecte les invariants. Vous pouvez même utiliser Sub::Install de CPAN pour importer la fonction $preparer_coupe_triporteur dans un autre espace de noms.

Ce n'est que le début de ce que vous pouvez faire avec les fonctions d'ordre supérieur. Le livreHigher Order Perl de Mark Jason Dominus est la référence canonique sur les fonctions de première classe et les fermetures de Perl. Vous pouvez le lire gratuitement en ligne à http://hop.perl.plover.com/(7).

Les attributs ont leurs inconvénients. Le pragma canonique pour travailler avec des attributs (le module attributes) répertorie son interface comme expérimentale depuis de nombreuses années, et à juste titre. Le module standard Attribute::Handlers de Damian Conway est beaucoup plus facile à utiliser et Attribute::Lexical de Andrew Main est une approche plus récente. Préférez l'un des deux à attributes lorsque c'est possible.

Le pire aspect des attributs, c'est qu'ils le rendent facile à déformer la syntaxe de Perl de façon imprévisible. Il n'est pas toujours facile de prédire ce que fera le code contenant des attributs. Une bonne documentation aide, mais si une déclaration apparemment innocente d'une variable lexicale stocke quelque part une référence vers cette variable, vos attentes sur sa durée de vie peuvent être erronées. De même, un gestionnaire peut envelopper une fonction dans une autre fonction et la remplacer dans la table de symboles à votre insu — imaginez un attribut :memoize qui appelle automatiquement le module standard Memoize.

Les attributs peuvent vous aider à résoudre des problèmes difficiles ou rendre une API plus facile à utiliser. Lorsqu'ils sont utilisés correctement ils sont puissants, mais la plupart des programmes n'en ont jamais besoin.

Un modèle commun dans la programmation OO (MooseMoose) est de déléguer ou d'envoyer par proxy certaines méthodes d'un objet à un autre objet en quelque sorte accessible au premier. Un proxy de journalisation peut faciliter le débogage :

package Proxy::Log;

# le constructeur lie une référence à un scalaire

sub AUTOLOAD
{
    my ($nom) = our $AUTOLOAD =~ /::(\w+)$/;
    Log::method_call( $nom, @_ );

    my $self = shift;
    return $$self->$nom( @_ );
}

Cette AUTOLOAD() extrait le nom de la méthode non définie. Ensuite, elle déréférence l'objet envoyé par proxy à partir d'une référence scalaire liée, enregistre l'appel de méthode, puis appelle cette méthode sur l'objet proxy avec les paramètres fournis.

Cette double recherche est facile à écrire, mais inefficace. Chaque appel de méthode sur le proxy doit d'abord échouer dans sa recherche de méthode dans l'arbre d'héritage avant de se retrouver enfin dans AUTOLOAD(). Payez cette pénalité juste une seule fois par l'installation de nouvelles méthodes dans la classe proxy lorsque le programme a besoin d'elles :

sub AUTOLOAD
{
    my ($nom)   = our $AUTOLOAD =~ /::(\w+)$/;
    my $methode = sub { ... };

    no strict 'refs';
    *{ $AUTOLOAD } = $methode;
    return $methode->( @_ );
}

Le corps de la fonction AUTOLOAD() précédente est devenu une fermeture (FermeturesFermetures) liée au nom de la méthode non définie. L'enregistrement de cette fermeture dans la table de symboles appropriée permet à toutes les recherches ultérieures de la méthode de trouver la fermeture créée (et d'éviter AUTOLOAD()). Finalement, ce code appelle directement la méthode et retourne le résultat.

Bien que cette approche soit plus propre et presque toujours plus transparente que la manipulation du comportement directement dans AUTOLOAD(), le code appelé par AUTOLOAD() peut voir AUTOLOAD() dans la liste de ses appelants en invoquant caller(). Si cela survient, non seulement ce serait une violation de l'encapsulation, la fuite des détails sur comment un objet fournit une méthode violerait également l'encapsulation.

Certains programmes utilisent des appels de fonction terminaux (TailcallsAppels de fonctions terminaux et récursion) pour remplacer l'invocation courante de AUTOLOAD() par un appel à la méthode de destination :

sub AUTOLOAD
{
   my ($nom)   = our $AUTOLOAD =~ /::(\w+)$/;
   my $methode = sub { ... }

   no strict 'refs';
   *{ $AUTOLOAD } = $methode;
   goto &$methode;
}

Cela a le même effet que l'appel direct de $methode, sauf que AUTOLOAD() n'apparaîtra plus dans la liste des appelants retournée par caller(), ce qui donne l'impression que la méthode générée a été appelée directement.

AUTOLOAD() peut être utile, mais il est difficile de l'utiliser correctement. L'approche naïve à générer des méthodes à l'exécution signifie que la méthode can() ne donnera pas des informations correctes sur les capacités des objets et des classes. La solution la plus simple est de déclarer préalablement toutes les fonctions que vous prévoyez utiliser dans AUTOLOAD() avec le pragma subs :

use subs qw( rouge vert bleu ocre cyan );

Cette technique documente bien votre intention, mais vous oblige à maintenir une liste statique de fonctions ou méthodes. Surcharger la méthode can() (Le paquetage UNIVERSALLe paquetage UNIVERSAL) fonctionne mieux parfois :

sub can
{
    my ($self, $methode) = @_;

    # utiliser les résultats  de la méthode can() parente
    my $meth_ref = $self->SUPER::can( $methode  );
    return $meth_ref if $meth_ref;

    # ajouter un filtre ici
    return unless $self->doit_generer( $methode );

    $meth_ref = sub { ... };
    no strict 'refs';
    return *{ $methode } = $meth_ref;
}

sub AUTOLOAD
{
    my ($self) = @_;
    my ($nom)  = our $AUTOLOAD =~ /::(\w+)$/;>

    return unless my $meth_ref = $self->can( $nom );
    goto &$meth_ref;
}

AUTOLOAD() est un gros marteau manquant de délicatesse et peut attraper des fonctions et méthodes que vous n'aviez pas l'intention de charger automatiquement, comme DESTROY(), le destructeur d'objets. Si vous écrivez une méthode DESTROY() sans implémentation, Perl se fera un plaisir de pointer vers elle plutôt que vers AUTOLOAD() :

# éviter AUTOLOAD()
sub DESTROY {}

Si vous mélangez fonctions et méthodes dans un seul espace de noms qui hérite d'un autre paquetage qui fournit son propre AUTOLOAD(), vous risquez de voir cette erreur étrange :

Si cela vous arrive, simplifiez votre code ; vous avez appelé une fonction qui n'existe pas dans un paquetage qui hérite d'une classe qui contient sa propre AUTOLOAD(). Le problème arrive de plusieurs manières : mélanger fonctions et méthodes dans un seul espace de noms est souvent un défaut de conception, l'héritage et AUTOLOAD() deviennent très rapidement complexes et raisonner sur le code est difficile lorsque vous ne savez pas quels objets les méthodes fournissent.

AUTOLOAD() est utile pour la programmation rapide et sale, mais un code robuste l'évite. (8)