Discussion :

[JUSTIN Loïc]

Bon, je me lance
Pour la 1er ligne de code
si l’élément courant ($_) est egale à *NULL* alors on prend la 1er valeur du tableau définie par $h{POOL}[0] que l'on assigne à $h{SCHEDPOOL}[0].
Pour la 2eme ligne de code
On prend tous les éléments de la liste que l'on aplatit et chaque élément de cette liste étant séparée par un ";"
Pour la 3eme ligne
je pense savoir mais j'ai un doute ...
Ne serais-ce pas dans le cas ou on aurait plusieurs enregistrements
SCHED SCHEDPOOL pour une CLASS
La fonction pop permet d'enlever et d'afficher le dernier element du tableau @{$h{$_}}

[cmcmc]

Pour plus de clarté je remets les lignes en question. Essaye d'expliquer à chaque fois la raison (si elle n'est pas évidente) et le mécanisme utilisé

Bon, je me lance
Pour la 1er ligne de code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        $_ eq '*NULL*' and $_ = $h{POOL}[0] for $h{SCHEDPOOL}[0];

si l’élément courant ($_) est egale à *NULL* alors on prend la 1er valeur du tableau définie par $h{POOL}[0] que l'on assigne à $h{SCHEDPOOL}[0].

OK pour le mécanisme Mais pourquoi est-ce qu'on fait ça ?

Pour la 2eme ligne de code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        print fic1_out +(join ';', map { @$_ } @h{@wanted}), "\n";

On prend tous les éléments de la liste que l'on aplatit et chaque élément de cette liste étant séparée par un ";"

un peu rapide
map { @$_ } ??? késako ?
@h{@wanted} ??? qu'est ce que c'est que cette bestiole ?

Pour la 3eme ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        pop @{$h{$_}} for qw(SCHED SCHEDPOOL);

je pense savoir mais j'ai un doute ...
Ne serais-ce pas dans le cas ou on aurait plusieurs enregistrements
SCHED SCHEDPOOL pour une CLASS
La fonction pop permet d'enlever et d'afficher le dernier element du tableau @{$h{$_}}

Et pourquoi est-ce qu'on veut enlever ces éléments ?

[JUSTIN Loïc]

Pour la 1ere ligne.
Le pourquoi, je dirais pour avoir une information complète pour le tableau @wanted
Ensuite
map{@$_} là, on travaille sur le tableau de la liste courante
@h{@wanted} cela correspond à un tableau de tableau et pour être franc, j'ai un peu de mal à comprendre son fonctionnement.
Et en dernier, je dirais bouclé sur la liste SCHED SCHEDPOOL pour pouvoir afficher la totalité des données

[cmcmc]

Pour la 1ere ligne.
Le pourquoi, je dirais pour avoir une information complète pour le tableau @wanted

peut mieux faire... Indication : relis mon premier message sur cette discussion.

...
@h{@wanted} cela correspond à un tableau de tableau
...

Je ne suis pas certain qu'on mette exactement la même signification derrière ces mots. Que signifient les formes suivantes ?

1. $a[$b]
2. $a[@b]
3. @a[@b]
4. $a{$b}
5. $a{@b}
6. @a{@b}

Prends ton temps pour répondre, lis des docs, des tutoriaux, etc. Il n'y a pas le feu , ton script fonctionne et tu peux t'en servir, c'est juste pour être certain que tu comprends vraiment ce qu'il fait afin que tu puisse le faire évoluer (ce que tu as déjà fait sur d'autres points ) dans le futur en toute confiance sur ces lignes

[JUSTIN Loïc]

Bonjour
un grand merci à @cmcmc pour ton aide.
J’apprécie ta pédagogie.
Sinon, je vais me pencher plus sérieusement sur les différents points que j'ai encore du mal à appréhender et je ferais un retour ensuite.

[Lolo78]

Bonjour, une petite indication à propos de @h{@wanted} sous la forme d'une session sous le debugger Perl:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
  DB<22> %h = (jan => 1, feb =>2, mar => 3, apr => 4, may => 5);
 
  DB<23>  @a =  qw /apr mar jan/;;
 
  DB<24>  print join "-", @h{@a};
4-3-1
 
  DB<25>  print join "-", @h{ qw /apr mar jan/};
4-3-1

[Philou67430]

La plus déroutante sera sans doute celle-ci : $a[@b], à essayer par exemple avec @a = (qw/jan fev mar avr mai/) et @b = (0..3)

[JUSTIN Loïc]

Voici quelques tests que j'ai lancé, pour essayer de comprendre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
use strict;
use warnings;
my %h = (jan => 1, feb =>2, mar => 3, apr => 4, may => 5);
my @a =  qw /jan feb mar apr may/;
my @b= (0..3);
print +(join "-", @h{@a}),"\n";
print +(join "-", @h{ qw /apr mar jan/}),"\n";
print +(join "-", $a[@b]),"\n";
##print +(join "-", $a[$b]),"\n";
print +(join "-", @a[@b]),"\n";
##print +(join "-", $a{$b}),"\n";
##print +(join "-", $a{@b}),"\n";
##print +(join "-", @a{@b}),"\n";

Et voici le résultat

1-2-3-4-5
4-3-1
may
jan-feb-mar-apr

Cela correspond aux resultats des lignes 6,7,8 et 10

[Lolo78]

Dans:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

print +(join "-", @h{ qw /apr mar jan/}),"\n";

l'expression

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

@h{ qw /apr mar jan/}

commence par une @, ce qui indique que c'est un tableau. C'est un tableau constitué des éléments du hachage dont les clefs sont dans le tableau qw /apr mar jan/. Cela s'appelle une "tranche de hachage" (hash slice). Les valeurs 4-3-1 correspondent bien aux mois "apr mar jan" du hachage.

De même, sur ta ligne 10, l'expression @a[@b] est une tranche de tableau, un tableau contenant les éléments 0 à 3 du tableau @a.

La ligne 8 est un exemple de ce qu'il ne faut pas faire.

[JUSTIN Loïc]

commence par une @, ce qui indique que c'est un tableau. C'est un tableau constitué des éléments du hachage dont les clefs sont dans le tableau qw /apr mar jan/. Cela s'appelle une "tranche de hachage" (hash slice). Les valeurs 4-3-1 correspondent bien aux mois "apr mar jan" du hachage.

Pour cette partie, je commence à comprendre

De même, sur ta ligne 10, l'expression @a[@b] est une tranche de tableau, un tableau contenant les éléments 0 à 3 du tableau @a.

Là, c'est logique pour moi

La ligne 8 est un exemple de ce qu'il ne faut pas faire.

Ici, je me rend bien compte que le résultat est faux, cela veut dire qu'on ne doit pas utiliser cette syntaxe ??

Ps: @lolo78 j'ai décomposé manuellement ton message, je ne sais si je l'ai fait dans les règles

[Lolo78]

Ps: @lolo78 j'ai décomposé manuellement ton message, je ne sais si je l'ai fait dans les règles

Aucun souci pour moi, et je trouve que c'est une excellente manière de dire précisément ce à quoi on répond.

En ce qui concerne la ligne 8, le sigil initial ($) dit que c'est un scalaire ordinaire (valeur unique) mais le tableau dans l'indice renvoie plusieurs valeurs. Ce n'est pas bon du tout. Dans ce genre de cas, le comportement de Perl est assez variable: si on affecte un tableau à un scalaire, le scalaire prend pour valeur le nombre d'éléments du tableau (ce comportement est bien défini et fiable); mais si on affecte une liste à un scalaire, le scalaire prend la valeur du dernier élément de la liste (si on affecte une tranche de tableau à un scalaire, on obtient aussi le dernier élément de la tranche); dans d'autres circonstances, le scalaire prend la première valeur. Bref, ce genre de cas comme $a[@b] (qui n'a pas vraiment de sens) devient scabreux et doit être à mon avis évité, à moins de vouloir remporter un concours de code incompréhensible (il y en a eu, je ne sais pas si ça existe encore).

[cmcmc]

Que signifient les formes suivantes ?...

Avant de répondre, complétons la liste :

1. $a[$b]
2. $a[@b]
3. @a[$b]
4. @a[@b]
5. $a{$b}
6. $a{@b}
7. @a{$b}
8. @a{@b}

à laquelle on ajoutera les formes littérales

1. $a[exp1, exp2, ... , expN]
2. @a[exp1, exp2, ... , expN]
3. $a{exp1, exp2, ... , expN}
4. @a{exp1, exp2, ... , expN}

Bon. C'est parti...

A l'exception (notable) des appels de fonctions ou méthodes de la forme $x(...) ou $x->(...), on peut interpréter précisément une forme £a<¤b>, où £ et ¤ sont deux sigils (signes) parmi $, @ ou % (on ignore ici & et *), et où la paire <> représente soit les crochets [], soit les accolades {}.

Cette interprétation doit procéder selon un ordre précis.

Tout d'abord, le signe extérieur £ indique le type du résultat : scalaire pour $, liste (tableau) pour @.

• $a<¤b> sera donc un scalaire
• @a<¤b> sera donc une liste (tableau), éventuellement vide ou réduite à un unique élément

Le type de 'parenthèses' <> quant à lui détermine le type de a : liste (tableau) pour [], tableau associatif (hash) pour {}.

• $a[¤b] sera donc un scalaire extrait de la liste @a
• @a[¤b] sera donc une liste extraite de la liste @a
• $a{¤b} sera donc un scalaire extrait du hash %a
• @a{¤b} sera donc une liste extraite du hash %a

Notez bien qu'on ignore complètement ¤b à ce stade.

Petit point de terminologie : les (sous) listes extraites de listes (tableaux) ou tableaux associatifs (hashes) -- lorsque le sigil (signe) extérieur est @ -- portent le nom de tranches (en anglais slices), et l'opération correspondante est logiquement appelée un tranchage (en anglais slicing).

Reste donc enfin à interpréter le pauvre ¤b qui n'a pas eu son mot à dire jusqu'à présent. Eh bien ça ne s'arrange pas pour lui car la chose à bien comprendre ici est que cette interprétation se fait en fonction du contexte imposé par le sigil (signe) extérieur : contexte scalaire si le signe externe est $, contexte de liste si c'est un @, et ceci quel que soit le signe interne ¤.

Or,

• en contexte scalaire, $b signifie le scalaire $b
• en contexte de liste, $b signifie la liste à un élément ($b)
• en contexte scalaire, @b signifie la taille (le nombre d'éléments) de la liste (tableau) @b
• en contexte de liste, @b signifie la liste @b

et donc au final, sans surprise sauf une exception

1. $a[$b] sera donc le scalaire en position scalaire $b dans la liste @a
2. $a[@b] sera donc le scalaire en position (nombre d'éléments dans la liste @b) dans la liste @a
3. @a[$b] sera donc une liste à un élément, le scalaire en position scalaire $b dans la liste @a
4. @a[@b] sera donc la liste (tranche) des élements de la liste @a dont les positions sont énumérées dans la liste @b
5. $a{$b} sera donc la valeur scalaire associée à la clé scalaire $b dans le hash %a
6. $a{@b} c'est l'exception annoncée : ici perl calcule en fait join $;, @b pour produire une clé, le résultat sera donc la valeur scalaire associée à la clé (join $;,@b) dans le hash %a; ce mécanisme est utilisé pour implémenter des tableaux associatifs 'multidimensionnels'.
7. @a{$b} sera donc une liste à un élément, la valeur associée à la clé scalaire $b dans le hash %a
8. @a{@b} sera donc la liste (tranche) des valeurs associées dans le hash %a aux clés énumérées dans la liste @b

Le forme 2 ci-dessus peuvent sembler un peu déroutante. Elle a cependant son utilité. Par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$a[@a] = expression

permet de faire croître le tableau @a d'un élément et d'un seul, initialisé par le résultat de expression évaluée en contexte scalaire, alors que la forme apparemment similaire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

push @a, expression

évalue expression en contexte de liste, et peut donc ajouter un nombre quelconque (y compris zéro) d'éléments à @a.

Quid des formes littérales ? Elles suivent les même règles que ci-dessus. En préambule, rappelons la signification de l'opérateur ',' (virgule, en anglais comma)

• en contexte scalaire, ',' évalue l'expression à sa gauche, ignore sa valeur, puis évalue l'expression à sa droite et retourne la valeur produite par cette dernière. Lorsque plusieurs expressions sont ainsi séparées par des ',', elles sont évaluées les unes après les autres, de gauche à droite, et c'est la valeur de la dernière à droite qui est retournée.
• en contexte de liste, les expressions séparées par des ',' sont évaluées de gauche à droite elles mêmes en contexte de liste, et leurs résultats (scalaires ou listes) assemblés en une liste composite unique (et aplatie).

Munis de ces informations,

1. $a[exp1, exp2, ... , expN] ici exp1, exp2, ... , expN est interprétée en contexte scalaire, c'est donc la valeur de expN évaluée en contexte scalaire qui l'emporte, et on retourne l'élément scalaire d'index cette valeur dans le tableau @a
2. @a[exp1, exp2, ... , expN] ici on retourne la liste (tranche) des éléments de la liste @a dont les positions sont énumérées dans la liste aplatie résultant de l'évaluation en contexte de liste de exp1, exp2, ... , expN
3. $a{exp1, exp2, ... , expN} c'est la même exception que précédemment : ici perl calcule en fait join $;, exp1, exp2, ... , expN ; on est dans un appel de fonction, qui impose un contexte de liste, et exp1, exp2, ... , expN sont donc évalués en contexte de liste ; le résultat est ensuite utilisé comme clé : on retourne donc la valeur scalaire associée dans le hash %a à cette clé. Ce mécanisme permet d'implémenter des tableaux associatifs 'multidimensionnels'.
4. @a{exp1, exp2, ... , expN}ici on retourne la liste (tranche) des valeurs dans le hash %a dont les clés sont énumérées dans la liste aplatie résultant de l'évaluation en contexte de liste de exp1, exp2, ... , expN

Ouf ! J'espère avoir été clair et complet. Si ce n'est pas le cas manifestez vous . Dans tous les cas merci de voter pour (ou contre) ce message et/ou cette discussion

[Lolo78]

Pour moi, les formes 2 et 6 sont à proscrire et les formes 3 et 7 sont au mieux douteuses ou trompeuses. Dans les quatre cas, on peut faire mieux et plus clair autrement.

Dans tous les cas merci de voter pour (ou contre) ce message et/ou cette discussion

C'est la seconde fois que je te vois demander des votes, mais toi, tu ne votes pratiquement jamais sur les postes des autres.

[JUSTIN Loïc]

bonjour
@lolo78 et @cmcmc
Pour vos explications qui me permettent d'avancer dans le bon sens ...
Ps: je n'ai pas toujours le réflexe de voter pour un message même si je trouve que le message est pertinent.

[cmcmc]

Pour moi, les formes 2 et 6 sont à proscrire

à proscrire ? Comme tu y vas ! Pour ma part je me sers des deux sans états d'âme. Mais il faut effectivement savoir les lire. Il m'arrive de remplacer occasionnellement $a[@b] par $a[scalar(@b)] ou $a[0+@b] mais les raisons pour le faire sont à mon avis souvent elles-mêmes douteuses

Je réfléchissais d'ailleurs à introduire la 6 dans cette discussion. Tu noteras que j'y ai introduit préalablement (et pédagogiquement ) l'expression explicite join $sep, liste

et les formes 3 et 7 sont au mieux douteuses ou trompeuses. Dans les quatre cas, on peut faire mieux et plus clair autrement.

Ton affirmation ci-dessus aurait plus de poids si elle était supportée par des exemples de formes meilleures et plus claires. A mon avis et a contrario, ces formes ont parfaitement leur place dans un code comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
return condition
       ? @a{$x}
       : @a{$x, $y};

D'une manière générale je n'aime pas trop ce type de proscriptions, que je trouve dégradantes par rapport à la solution par le haut qui consiste à maîtriser le sujet. Elles peuvent être utiles pendant un temps pour un débutant mais il risque de le rester s'il en est prisonnier. Mais bon, si c'est ton truc, Perl::Critic est ton ami

Dans tous les cas merci de voter pour (ou contre) ce message et/ou cette discussion

C'est la seconde fois que je te vois demander des votes, mais toi, tu ne votes pratiquement jamais sur les postes des autres.

C'est parce que tu en as manqué une. Dans les trois cas où j'ai, comme tu dis, demandé des votes, les messages correspondants m'avaient pris largement plus de deux heures à composer. Dans de tels cas un peu de feedback est bienvenu pour que je ne sois pas tenté par l'alternative oh combien séduisante de faire autre chose de mon temps.

Enfin je vote peu (ça m'arrive, essentiellement positivement) parce que me retiens. Je n'aime pas les fautes d'orthographe ou de syntaxe, ni les imprécisions ou approximations. On ne se refait pas...

[Lolo78]

à proscrire ? Comme tu y vas ! Pour ma part je me sers des deux sans états d'âme. Mais il faut effectivement savoir les lire. Il m'arrive de remplacer occasionnellement $a[@b] par $a[scalar(@b)] ou $a[0+@b] mais les raisons pour le faire sont à mon avis souvent elles-mêmes douteuses

Je sais les lire, merci.

Mais même si j'aime utiliser des formulations de code concises, je pense qu'il faut, en général, savoir expliciter son code, dire ce qu'il fait en terme du contenu fonctionnel.

Plutôt que $a[@b] ou même $a[scalar(@b)] qui n'apporte pas grand chose de plus, je préfère écrire un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
my $nb_prestas = @b ; # ou my $nb_prestas = scalar @b;
my $something = $a[$nb_prestas];

La différence, c'est que l'on a ajouté un nom de variable qui commente le code.

[quote=cmcmc;7516646]
Ton affirmation ci-dessus aurait plus de poids si elle était supportée par des exemples de formes meilleures et plus claires.[/code]

@a[$b] par exemple? pourquoi pas par exemple ($a[$b]), bien plus claire?

D'une manière générale je n'aime pas trop ce type de proscriptions, que je trouve dégradantes par rapport à la solution par le haut qui consiste à maîtriser le sujet. Elles peuvent être utiles pendant un temps pour un débutant mais il risque de le rester s'il en est prisonnier. Mais bon, si c'est ton truc, Perl::Critic est ton ami

Je ne veux pas proscrire quoi que ce soit, et n'aime pas non plus les interdictions. Je veux produire du code suffisamment facile à comprendre pour ceux qui vont devoir maintenir ce code (notamment et surtout si c'est moi). Depuis que je suis arrivé dans la structure où je travaille actuellement, j'ai réussi à convaincre 5 collègues d'utiliser Perl pour une grosse partie de ce que nous faisons le plus souvent (et le sixième et dernier collègue à résister est en train de céder et de changer d'avis). Je n'y serais pas arrivé si je leur avais donné du Golf ou du Perl Obfuscated Contest à maintenir. Après, je reconnais que tout cela est difficile à juger, j'hésite bien souvent sur le niveau à utiliser: fonctions de rappel, fermeture, tables de répartition, etc. jusqu'où aller?

Je n'ai jamais utilisé Perl::Critic et n'ai pas l'intention de le faire (mais le livre de Damian Conway PBP m'a cependant beaucoup appris).

[cmcmc]

La différence, c'est que l'on a ajouté un nom de variable qui commente le code.

C'est un point délicat et qui me semble-t-il demande beaucoup de tact quand on le généralise. Je crois avoir passé un seuil en Perl à partir du moment ou j'ai commencé à minimiser mon utilisation de variables nommées au profit de $_ et d'une lecture correcte des indexations et tranchages. C'est pourquoi je m'attache maintenant à faire partager cette vue aux débutants auxquels je m'adresse. En mode pédagogique, j'essaie de minimiser les variables additionnelles, fussent elles 'documentaires'. Mais je ne le fais que pour des blocs courts, où on ne risque pas de perdre le fil sur ce qu'est le sujet du discours $_. En programmation orientée objet, cela paye assez vite car les corps de méthode sont souvent effectivement très courts. Je suis par ailleurs devenu fan de la topicalisation par for. En fait, les variables 'documentaires' me semblent souvent parasites et au final plus nuisibles qu'utiles. Mais ce n'est pas facile de positionner correctement le curseur...

... Je n'y serais pas arrivé si je leur avais donné du Golf ou du Perl Obfuscated Contest à maintenir.

Certainement pas, effectivement, mais je crois qu'il est possible d'écrire du code qui soit à la fois concis et intelligible. Le problème est que celui qui lit ce code doit, pour être en mesure d'intervenir utilement dessus, avoir un minimum de connaissances des capacités de Perl, et donc un minimum de formation. Il sait probablement écrire du C ou équivalent, et donc la formation qu'il doit recevoir doit porter à mon avis dès le départ sur ce qui fait la magie (et la difficulté) de Perl quand on le maîtrise (resp. quand on ne le maîtrise pas...). D'où mes efforts en ce sens, que tu semble considérer mal placés

Je n'ai jamais utilisé Perl::Critic et n'ai pas l'intention de le faire (mais le livre de Damian Conway PBP m'a cependant beaucoup appris.

Personnellement je le trouve éclairant même s'il y a un travail de configuration significatif à faire pour le tailler à ses propres besoins.

[Philou67430]

C'est un point délicat et qui me semble-t-il demande beaucoup de tact quand on le généralise. Je crois avoir passé un seuil en Perl à partir du moment ou j'ai commencé à minimiser mon utilisation de variables nommées au profit de $_ et d'une lecture correcte des indexations et tranchages. C'est pourquoi je m'attache maintenant à faire partager cette vue aux débutants auxquels je m'adresse.

C'est amusant, je suis un parcours totalement opposé, où je supprime au maximum toute utilisation de $_ et @_, variables automatiques "à tout faire", certes lexicalement locales, mais surtout, sujettes au masquage (impossible par exemple d'imbriquer deux boucles avec $_ tout en conservant la possibilité d'accéder aux deux valeurs de boucles).
Ainsi, je n'utilise JAMAIS de boucle foreach avec $_. J'affecte immédiatement à l'entrée d'une fonction @_ à une liste de variables nommées. Dans un pipeline de fonction de liste, si le code de la fonction excède une instruction, j'affecte $_ à une variable nommée...

Dans le même ordre d'idée, j'évite systématiquement l'usage de variables à effet de bord telles que les $1, $2 des regexp, au profit de d'affectations de liste immédiate.

Ces manières de faire me semblent plus robustes face à la maintenance du code (notamment par plusieurs personnes différentes), car elles souffrent moins d'ajouts/suppressions de code. En plus, elles sont souvent plus "lisibles".

[cmcmc]

C'est amusant, je suis un parcours totalement opposé, où je supprime au maximum toute utilisation de $_ et @_, variables automatiques "à tout faire", certes lexicalement locales, mais surtout, sujettes au masquage (impossible par exemple d'imbriquer deux boucles avec $_ tout en conservant la possibilité d'accéder aux deux valeurs de boucles).
Ainsi, je n'utilise JAMAIS de boucle foreach avec $_. J'affecte immédiatement à l'entrée d'une fonction @_ à une liste de variables nommées. Dans un pipeline de fonction de liste, si le code de la fonction excède une instruction, j'affecte $_ à une variable nommée...

Dans le même ordre d'idée, j'évite systématiquement l'usage de variables à effet de bord telles que les $1, $2 des regexp, au profit de d'affectations de liste immédiate.

Ces manières de faire me semblent plus robustes face à la maintenance du code (notamment par plusieurs personnes différentes), car elles souffrent moins d'ajouts/suppressions de code. En plus, elles sont souvent plus "lisibles".

Oui je pourrais peut être en rire si ce n'était pas aussi affreusement triste. Ce genre d'attitude est probablement la raison principale pour laquelle tant de gens ne dépassent jamais le stade du baby-Perl (ou 'C en Perl').

Je peux supporter l'utilisation occasionnelle de variables 'documentaires', et le nommage explicite de tout ou partie de @_ en entrée de sub ne m'est pas étranger, pas plus que le nommage des variables dans des boucles imbriquées. Mais se priver délibérément des topicaliseurs et des possibilités d'aliasing de $_ et @_ est à mon avis irresponsable.

En 30 ans j'ai codé en assembleur, PL-1, Pascal, Fortran, C, C++, Lisp, Prolog, Sheme, Visual Basic, Java, Javascript, Python, PHP, et j'en oublie. J'ai entendu ce genre d'arguments prononcés pour tous les langages 'fonctionnels'. Les appliquer comme tu le proposes à Perl, qui est devenu depuis 10 ans mon langage quasi exclusif quand j'ai le choix, c'est selon moi se couper un bras.

Comme dit le proverbe, on peut faire du FORTRAN dans n'importe quel langage.

A mon avis les arguments portant sur la maintenabilité supposée accrue du code ne tiennent pas, mais c'est peut-être parce que j'ai parallèlement une politique de test très agressive dont l'impact positif sur la maintenance est à plusieurs ordres de grandeurs de celui des conventions de codage.

[Philou67430]

Je pratique perl depuis plus de 15 ans... et je pense honnêtement avoir largement dépassé le stade du "C en perl" (je ne l'ai d'ailleurs jamais pratiqué, de mémoire).

L'usage des topicalizer est utile et pratique lorsque leur étendue (autant en largeur qu'en profondeur d'imbrication) est limitée (règle de bonne pratique). C'est mon avis, et ne pas le partager n'implique pas que je sois un affreux manchot triste