Perl moderne : 2014

Bien que le pragma strict (PragmasPragmas) interdise à juste titre les mots nus ambigus, certains mots nus sont acceptables.

XII-A-1-a. Mots nus comme clés de hachage▲

# le 'shift' littéral est la clé
my $valeur = $elements{shift};

# la valeur produite par shift est la clé
my $valeur = $elements{shift @_}

# la fonction retourne la clé
my $valeur = $elements{myshift( @_ )}

# le plus unaire utilise la fonction shift
my $valeur = $elements{+shift};

XII-A-1-b. Mots nus comme noms de paquetage▲

# probablement une méthode de classe 
Package->method;

# certainement une méthode de classe
Package::->method;

# une méthode de classe un peu moins laide
'Package'->method;

XII-A-1-c. Mots nus comme noms de bloc de code▲

package Singe::Butler;

BEGIN { initialiser_simiens( __PACKAGE__ ) }

sub AUTOLOAD { ... }

XII-A-1-d. Mots nus comme constantes▲

# n'utilisez pas ceci pour une vraie authentification
use constant NAME     => 'Bucky';
use constant PASSWORD => '|38fish!head74|';

return unless $nom eq NAME && $pass eq PASSWORD;

Même si vous codez très prudemment, les mots nus produisent toujours du code ambigu. Vous pouvez éviter les pires abus, mais vous rencontrerez plusieurs types de mots nus dans le code hérité.

XII-A-2-a. Mots nus comme valeurs de hachage▲

# mauvais style; ne l'utilisez pas
my %parents =
(
    mere => Annette,
    pere => Floyd,
);

XII-A-2-b. Mots nus comme appels de fonction▲

XII-A-2-c. Mots nus comme descripteurs de fichiers▲

XII-A-2-d. Mots nus comme fonctions de tri▲

# style mot nu
my @sorted = sort comparer_longueurs @unsorted;

# référence de fonction dans un scalaire
my $comparaison = \&comparer_longueurs;
my @sorted      = sort $comparaison @unsorted;

# ne fonctionne pas
my @sorted = sort \&comparer_longueurs @unsorted;

Dans la forme d'objet indirect (ou, plus précisément, le cas datif) du premier exemple, le verbe (la méthode) précède le substantif (l'objet) auquel il se réfère. Cela est très bien dans les langues parlées, mais introduit des ambiguïtés d'analyse syntaxique en Perl.

Comme le nom de la méthode est un mot nu (Mots nusMots nus), le compilateur utilise plusieurs heuristiques pour deviner l'interprétation correcte de ce code. Bien que ces heuristiques soient bien testées et presque toujours justes, leurs modes de défaillance sont source de confusion. Les choses s'aggravent lorsque vous passez des arguments à un constructeur :

# NE PAS UTILISER
my $obj = new Classe( arg => $valeur );

Dans cet exemple, le nom de la classe ressemble à un appel de fonction. Perl peut lever l'ambiguïté de grand nombre de ces cas, mais ses heuristiques dépendent des noms de paquetage que le compilateur a vus, des mots nus qu'il a déjà résolus (et comment il les a résolus) et des noms des fonctions déjà déclarées dans le paquetage actuel. Pour une liste exhaustive de ces conditions, vous devez lire le code source du compilateur Perl — pas quelque chose que le programmeur Perl moyen veut faire.

Imaginez un problème avec une fonction prototypée (PrototypesPrototypes) dont le nom se trouve par accident entrer en conflit avec le nom d'une classe ou d'une méthode appelée indirectement. Cela est rare (c'est arrivé à votre auteur en utilisant le module JSON), mais tellement désagréable à déboguer qu'il vaut mieux d'éviter les appels indirects.

Un autre danger de la syntaxe indirecte est que le compilateur attend comme objet une expression scalaire unique. L'écriture dans un descripteur de fichier stocké dans une variable agrégat (tableau ou hachage) semble évidente, mais ne l'est pas :

# NE FONCTIONNE PAS COMME CECI
say $config->{output} 'Message de diagnostic amusant !';

Perl tentera d'appeler say sur l'objet $config.

Toutes les commandes internes fonctionnant sur des descripteurs de fichiers — print, close et say — fonctionnent d'une façon indirecte. C'était bien quand les descripteurs de fichiers étaient des variables globales de paquetage, mais les descripteurs lexicaux de fichiers (Références de descripteur de fichierRéférences de descripteur de fichier) mettent en évidence les problèmes de syntaxe objet indirecte. Pour résoudre ce problème, levez l'ambiguïté de la sous-expression qui produit l'invoquant prévu :

say {$config->{output}} 'Message de diagnostic amusant !';

La syntaxe d'invocation directe ne souffre pas de ce problème d'ambiguïté. Pour construire un objet, appelez la méthode constructeur directement sur le nom de la classe :

my $q   = Plack::Request->new;
my $obj = Class->new( arg => $value );

Cette syntaxe présente toujours un problème de mot nu dans le sens où, si vous avez une fonction nommée Request dans l'espace de noms de Plack, Perl interprétera le nom nu de classe comme un appel à la fonction, comme ceci :

sub Plack::Request;

# vous avez écrit Plack::Reuqest->new, mais Perl a compris
my $q = Plack::Request()->new;

Même si cela arrive rarement, vous pouvez lever l'ambiguïté des noms de classe en ajoutant le séparateur de paquetage (::) ou en marquant explicitement les noms de classe comme des chaînes littérales :

# séparateur de paquetage
my $q = Plack::Request::->new;

# une chaîne littérale sans ambiguïté
my $q = 'Plack::Request'->new;

Presque personne ne fait cela.

Pour les cas limités aux opérations sur descripteurs de fichiers, l'utilisation du datif est tellement répandue que vous pouvez utiliser l'approche de l'appel indirect si vous entourez par des accolades votre invoquant prévu. Si vous utilisez Perl 5.14 ou plus récent (ou si vous chargez IO::File ou IO::Handle), vous pouvez utiliser des méthodes sur descripteurs lexicaux de fichiers. Presque personne ne le fait pour print et say.

Le module Perl::Critic::Policy::Dynamic::NoIndirect du CPAN (un plug-in pour Perl::Critic) peut analyser votre code pour trouver les appels indirects. Le module indirect du CPAN permet d'identifier et d'interdire leur utilisation dans des programmes en cours d'exécution :

# avertit sur l'utilisation des appels indirects
no indirect;

# signale une exception lors de leur utilisation
no indirect ':fatal';

Les prototypes changent la façon dont Perl analyse votre code et produit une coercition sur les arguments de vos fonctions. Alors que ces prototypes peuvent ressembler superficiellement à des signatures de fonction dans d'autres langages, ils sont très différents. Ils ne documentent ni le nombre ni les types d'arguments que les fonctions attendent, ni n’effectuent le mappage entre arguments et paramètres nommés.

Les coercitions de prototype fonctionnent de façon subtile, comme l'application du contexte scalaire sur des arguments reçus :

sub egalite_numerique($$)
{
    my ($left, $right) = @_;
    return $left == $right;
}

my @nombres = 1 .. 10;

say 'Sont égaux, quoi que cela signifie !'
    if egalite_numerique @nombres, 10;

... mais fonctionnent uniquement sur des expressions simples :

sub mypush(\@@);

# erreur de compilation : prototype non concordant
# (attend un tableau, reçoit l'affectation d'un scalaire)
mypush( my $elems = [], 1 .. 20 );

Pour déboguer cela, les utilisateurs de mypush doivent connaître à la fois si un prototype existe, et les limitations du prototype de tableau.

Les prototypes ont quelques bons usages qui l'emportent sur leurs problèmes. Par exemple, vous pouvez utiliser une fonction prototypée pour redéfinir une des commandes internes de Perl. Vérifiez d'abord si vous pouvez redéfinir la commande interne en examinant son prototype dans un petit programme de test. Ensuite, utilisez le pragma subs pour dire à Perl que vous envisagez de redéfinir une commande interne, et enfin déclarez votre redéfinition avec le prototype correct :

use subs 'push';

sub push (\@@) { ... }

Faites attention, le pragma subs reste en vigueur pour le reste du fichier, indépendamment de toute portée lexicale.

La deuxième raison d'utiliser les prototypes est de définir des constantes lors de la compilation. Lorsque Perl rencontre une fonction déclarée avec un prototype vide (par opposition à aucun prototype) et si cette fonction est évaluée à une seule expression constante, l'optimiseur transformera tous les appels à cette fonction en des constantes au lieu d'appels de fonction :

sub PI () { 4 * atan2(1, 1) }

Tout le code ultérieur utilisera la valeur calculée de pi à la place du mot nu PI ou d'un appel à PI(), en respectant la portée et la visibilité.

Le pragma standard constant gère ces détails pour vous. Le module Const::Fast du CPAN crée des scalaires constants que vous pouvez interpoler dans des chaînes.

Une utilisation raisonnable des prototypes est d'étendre la syntaxe de Perl pour fonctionner sur des fonctions anonymes en tant que blocs. Le module Test::Exception du CPAN l'utilise à bon escient pour fournir une belle API avec calcul retardé. Voir aussi Test::Fatal. Sa fonction throws_ok() accepte trois arguments : un bloc de code à exécuter, une expression régulière pour rechercher le message d'exception et une description facultative du test :

use Test::More;
use Test::Exception;

throws_ok
    { my $unobjet; $unobjet->yoink }
    qr/Impossible d'appeler la méthode "yoink" sur un indéfini/,
    'Une méthode sur un invoquant indéfini devrait échouer';

done_testing();

La fonction exportée throws_ok() a un prototype de &$;$. Son premier argument est un bloc qui devient une fonction anonyme. Le deuxième argument est un scalaire. Le troisième argument est facultatif.

Les lecteurs attentifs ont peut-être repéré l'absence de virgule après le bloc. C'est une bizarrerie du compilateur de Perl, qui attend un espace après un bloc prototypé, pas l'opérateur virgule. C'est un inconvénient de la syntaxe de prototype. Si cela vous gêne, utilisez throws_ok() sans profiter du prototype :

use Test::More;
use Test::Exception;

throws_ok(
    sub { my $unobject; $unobject->yoink() },
    qr/Impossible d'appeler la méthode "yoink" sur un indéfini/,
    'Une méthode sur un invoquant indéfini devrait échouer' );

done_testing();

Une dernière bonne utilisation des prototypes est lors de la définition d'une fonction nommée personnalisée à utiliser avec sort. Ben Tilly a proposé cet exemple :

sub length_sort ($$)
{
    my ($left, $right) = @_;
    return length($left) <=> length($right);
}

my @sorted = sort length_sort @unsorted;

Le prototype de $$ oblige Perl à passer les paires à trier dans @_. La documentation de sort suggère que c'est un peu plus lent que l'utilisation des variables globales de paquetage $a et $b, mais l'utilisation des variables lexicales compense souvent toute perte de vitesse.

Imaginez une classe avec plusieurs méthodes :

package Commande;

use List::Util 'sum';

...

sub calculer_prix
{
    my $self = shift;
    return sum( 0, $self->get_items );
}

Étant donné un objet Commande $c, les appels suivants de cette méthode peuvent sembler équivalents :

my $prix = $c->calculer_prix;

# mauvais; ne pas utiliser
my $prix = Commande::calculer_prix( $c );

Bien que dans ce cas simple, ces deux appels produisent le même résultat, le second viole l'encapsulation de l'objet passant outre la recherche de méthode dans l'arbre d'héritage.

Si $c était plutôt une sous-classe ou une allomorphe (RôlesRôles) de Commande qui redéfinissait calculer_prix(), le contournement de la recherche de méthode n'appellerait pas la bonne méthode. Toute modification de la mise en œuvre de calculer_prix(), par exemple une modification de l'héritage ou une délégation par AUTOLOAD() — pourrait conduire à l'échec du code appelant.

Perl a une situation où ce comportement peut sembler nécessaire. Si vous forcez la résolution de méthode sans recherche, comment voulez-vous invoquer la référence de la méthode qui en résulte ?

my $meth_ref = $c->can( 'appliquer_remise' );

Il existe deux possibilités. La première consiste à ignorer la valeur de retour de la méthode can() :

$c->appliquer_remise if $c->can( 'appliquer_remise' );

La seconde consiste à utiliser la référence elle-même avec la syntaxe d'appel de méthode :

if (my $meth_ref = $o->can( 'appliquer_remise' ))
{
    $o->$meth_ref();
}

Lorsque $meth_ref contient une référence de fonction, Perl appellera cette référence avec $c comme invoquant. Cela fonctionne même avec le pragma strict, comme lors de l'appel d'une méthode avec un scalaire contenant son nom :

my $nom = 'appliquer_remise';
$c->$nom();

Il existe un petit inconvénient à appeler une méthode par référence ; si la structure du programme change entre le stockage de la référence et l'appel de celle-ci, la référence peut ne plus se référer à la méthode la plus appropriée. Si la classe Commande a changé de telle sorte que Commande::appliquer_remise n'est plus la bonne méthode à appeler, la référence en $meth_ref ne sera pas mise à jour.

Lorsque vous utilisez cette forme d'appel, limitez la portée des références.

Comme Perl ne fait aucune distinction entre les fonctions et les méthodes au moment de leur déclaration et comme il est possible (mais déconseillé) d'appeler une fonction donnée comme une fonction ou une méthode, il est possible d'écrire une fonction appelable des deux façons.

Le module CGI a ces fonctions doubles. Chacune d'entre elles doit appliquer plusieurs heuristiques pour déterminer si le premier argument est un invoquant. Cela provoque des problèmes. Il est difficile de prédire exactement quels invoquants sont potentiellement valides pour une méthode donnée, surtout quand vous pouvez avoir affaire à des sous-classes. La création d'une API que les utilisateurs ne peuvent pas facilement mal utiliser est aussi plus difficile, sans parler de votre fardeau de documentation. Que se passe-t-il lorsqu'une partie du projet utilise l'interface procédurale et une autre utilise l'interface objet ?

Si vous devez fournir des interfaces procédurale et OO distinctes pour une bibliothèque, alors créez deux API séparées.

Pour lier une variable :

use Tie::File;
tie my @file, 'Tie::File', @args;

Le premier argument est la variable à lier. Le deuxième est le nom de la classe à laquelle le lier. @args est une liste optionnelle d'arguments requis pour la fonction de liaison. Dans le cas de Tie::File, @args devrait contenir un nom de fichier valide.

Les fonctions de liaison ressemblent aux constructeurs : TIESCALAR(), TIEARRAY(), TIEHASH(), ou TIEHANDLE() respectivement pour des scalaires, tableaux et hachages et descripteurs de fichiers. Chaque fonction retourne un nouvel objet qui représente la variable liée. Tant tie que tied retournent cet objet, bien que la plupart des gens utilisent tied dans un contexte booléen.

Pour mettre en œuvre la classe d'une variable liée, hériter d'un module standard tel que Tie::StdScalar (Tie::StdScalar ne possède pas son propre fichier .pm, alors écrivez use Tie::Scalar;), puis redéfinissez les méthodes spécifiques pour les opérations que vous souhaitez modifier. Dans le cas d'un scalaire lié, celles-ci sont probablement FETCH et STORE, éventuellement TIESCALAR(), et probablement pas DESTROY().

Voici une classe qui trace tous les accès en lecture et en écriture à un scalaire  :

package Tie::Scalar::Logged
{
    use Modern::Perl;

    use Tie::Scalar;
    use parent -norequire => 'Tie::StdScalar';

    sub STORE
    {
        my ($self, $valeur) = @_;
        Logger->log("Stocker <$valeur> (précédemment : [$$self])", 1);
        $$self = $valeur;
    }

    sub FETCH
    {
        my $self = shift;
        Logger->log("Récupérer <$$self>", 1);
        return $$self;
    }
}

Supposons que la méthode log() de classe Logger() prend en entrée une chaîne et le nombre d'appels de fonction à remonter dans la pile d'appels pour déterminer l'endroit dans le code que l'on désire signaler.

Dans les méthodes STORE() et FETCH(), $self fonctionne comme un scalaire lié à un objet au moyen de bless. L'affectation d'une valeur à cette référence scalaire modifie la valeur du scalaire et la lecture de celle-ci retourne sa valeur.

De même, les méthodes de Tie::StdArray et de Tie::StdHash agissent respectivement sur des références liées de tableau et hachage. Encore une fois, perldoc perltie explique les méthodes que les variables liées supportent, telles que la lecture ou l'écriture simultanée de plusieurs valeurs.

Les variables liées semblent offrir des occasions amusantes de réaliser des solutions ingénieuses, mais elles peuvent produire des interfaces déroutantes. Sauf si vous avez une très bonne raison pour créer des objets se comportant comme s'ils étaient des types internes de données, évitez de créer vos propres variables liées. Elles sont souvent beaucoup plus lentes que les types de données standard.

Cela dit, les variables liées peuvent vous aider à déboguer le code délicat (utilisez le scalaire tracé de l'exemple de module Tie::Scalar::Logged donné au paragraphe ci-dessus pour vous aider à comprendre où une valeur est modifiée) ou à rendre possibles certaines choses impossibles (accéder à des fichiers très volumineux sans manquer de mémoire). Les variables liées sont moins utiles en tant qu'interfaces primaires d'objets ; il est souvent trop difficile et trop contraignant d'essayer d'adapter l'ensemble de votre interface à celle soutenue par tie().

Un dernier mot d'avertissement est une triste mise en accusation de la programmation paresseuse : beaucoup de modules se plient en quatre pour empêcher l'utilisation des variables liées, ne serait-ce que par accident. C'est dommage, mais le code de la bibliothèque est parfois rapide ainsi et paresseux avec ce qu'il attend, et vous ne pouvez pas toujours y remédier.