Discussion :

[Lolo78]

Pour moi, l'utilisation de ce module, qu'il faut "installer manuellement", c'est un mauvais palliatif : je n'ai jamais vu de langage pour lequel il faudrait activer une option pour en corriger un bug
La vraie solution serait plutôt de rendre "use autovivification" comme un pragma à activer, alors que perl fonctionnerait par défaut en mode "no autovivification qw(fetch exists delete)". Il n'est pas normal qu'un mode de fonctionnement "déroutant" soit le mode de fonctionnement par défaut, d'autant plus s'il est magiquement démoniaque. Ce mode de fonctionnement dessert plus qu'il ne sert, c'est pourquoi j'évoquais dans mon premier post que c'était un bug et non une feature, et ce n'est pas l'existence de solutions qui me font changer d'avis sur ce point. C'est ma conclusion.

+ 1, entièrement du même avis.

Et j'ai beau chercher, je ne vois pas de bonnes raisons, si ce n'est l'éventuelle complexité qu'il y aurait à corriger ce problème.

[Lolo78]

D'expérience, pour tout ce qui touche à Perl, si quelque chose te gratte vraiment et que les développeurs n'en font pas une priorité, le plus rapide et efficace est de tenter de le résoudre toi même...

Yesss, ce serait une excellente idée, et je suis suffisamment redevable à Perl pour souhaiter contribuer plus activement, mais, perso, intégrer les P5P, je ne m'en sens pas capable, ou alors il me faudrait un investissement en temps considérable que je n'ai pas les moyens de faire dans l'immédiat.

[cmcmc]

OK, passons sur l'exception, qui est bien levée si l'auto-vivification n'est pas active et que l'on déréférence une variable undef en utilisant son résultat avec un opérateur qui n'accepte pas undef

Uuuuh?
Peux-tu donner un exemple ?

(l'exception est levée par l'opérateur qui n'accepte pas undef, pas par le déréférencement, ni par keys, qui visiblement, se satisfait de undef en paramètre, ce que je peux admettre).

Cela m'étonnerait fort que l'exception soit levée par l'opérateur. Là encore donne un exemple.

C'est effectivement l'effet de bord "auto-vivification" que je voulais signaler comme un bug, comme je l'explique dans la partie qui n'est pas entre parenthèse (partie qui était un corolaire sur lequel on peut effectivement discuter pour définir des solutions différentes).

Pardonne moi mais là encore je suis perdu. De quelle partie parles-tu exactement ? Donne 1) le lien 2) le texte s'il te plaît.

Ton discours, en revanche, était de contester l'inutilité de cette auto-vivification particulière, point sur lequel le fil entier pointe, et point sur lequel je souhaitais effectivement qu'il se concentre (qui sait, existe-t-il peut-être de vraies bonnes raisons à laisser en place un tel fonctionnement !DWIM).

Je répondrai à cela quand j'aurai compris le sens des paragraphes précédents. Merci d'avance de tes précisions.

[Philou67430]

Uuuuh?
Peux-tu donner un exemple ?

Cela m'étonnerait fort que l'exception soit levée par l'opérateur. Là encore donne un exemple.

Code :

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

1
2
perl -wE 'no autovivification;use strict; my $a;my $b = 1+$a->{0}'
Use of uninitialized value in addition (+) at -e line 1.

Pardonne moi mais là encore je suis perdu. De quelle partie parles-tu exactement ? Donne 1) le lien 2) le texte s'il te plaît.

La partie que j'ai considérée comme bug :

Habituellement, l'auto-vivification concerne la création de clés de hash automagiquement lors de leur accès en lecture ou en écriture (par un déréférencement de hash).
Ici, c'est un hash vide à a été créé à partir du néant

La discussion s'est ensuite orientée sur le fait que l'auto-vivification des rvalue ait lieu, alors qu'on s'attendrait à ce qu'elle n'ait pas lieu (selon le principe DWIM).

Je répondrai à cela quand j'aurai compris le sens des paragraphes précédents. Merci d'avance de tes précisions.

Tu peux ne pas répondre. C'est mon point de vue, et je ne t'oblige pas à le partager. La discussion a par ailleurs montré jusqu'à présent que tu ne m'as pas convaincu non plus, et j'ai des doutes que tu y parviennes encore à ce stade (de la conclusion).

[cmcmc]

Code :

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

1
2
perl -wE 'no autovivification;use strict; my $a;my $b = 1+$a->{0}'
Use of uninitialized value in addition (+) at -e line 1.

Calembredaines. Je ne vois pas d'exception ici, mais un warning, qui n'a rien à voir avec l'autovivification :

Code :

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

1
2
3
4
5
6
Taisha:~/tttmp $ perl -wE 'no autovivification; my $a;my $b = 1+$a->{0}'
Use of uninitialized value in addition (+) at -e line 1.
Taisha:~/tttmp $ perl -wE 'my $a;my $b = 1+$a->{0}'
Use of uninitialized value in addition (+) at -e line 1.
Taisha:~/tttmp $ perl -E 'my $a;my $b = 1+$a->{0}'
Taisha:~/tttmp $

La partie que j'ai considérée comme bug :

Habituellement, l'auto-vivification concerne la création de clés de hash automagiquement lors de leur accès en lecture ou en écriture (par un déréférencement de hash).
Ici, c'est un hash vide à a été créé à partir du néant

... Ton discours, en revanche, était de contester l'inutilité de cette auto-vivification particulière, point sur lequel le fil entier pointe, et point sur lequel je souhaitais effectivement qu'il se concentre (qui sait, existe-t-il peut-être de vraies bonnes raisons à laisser en place un tel fonctionnement !DWIM).

Pas de révisionnisme, s'il te plaît. Dans mes premières réponses j'ai essayé d'élargir ta conception manifestement étroite de l'autovivification au cas des tableaux et même des scalaires, puis tenté de corriger ta conception erronée du mécanisme de l'autovivification. J'ai ensuite pointé l'existence de modules sur CPAN qui permettent de limiter les autovivifications "indésirables" ou leur impact, tout en indiquant clairement que ce n'est pas un problème pour tout le monde. J'ai enfin fait valoir que prétendre maintenant faire considérer comme un bug un comportement connu depuis l'origine de Perl me semblait un combat d'arrière garde, et de plus dépourvu d'impact sur la grande majorité des utilisateurs, qui utilisera de toute façon pendant longtemps des versions de Perl dépourvues de tout support ou correctif sur ce point.

Mes réserves de tact étant épuisées à ce stade je vais écrire de manière probablement plus directe que je ne le devrais. Mon analyse de tes interventions sur ce fil est la suivante : suite à un bug dans ton code causé par ta propre méconnaissance du mécanisme de l'autovivification (malgré tes protestations du contraire), tu prétends exiger qu'un comportement que tu comprends mal soit considéré comme un bug de Perl. Effectivement, je refuse de te suivre dans cette voie.

Ce qui était utile dans ton post initial était, comme je l'ai signalé, la mise en évidence d'une circonstance dans laquelle une autovivification inattendue pouvait se produire. J'aurai pu plusser pour ce seul point. Mais comme le reste du post m'amenait à moinsser, je n'ai rien fait.

La discussion s'est ensuite orientée sur le fait que l'auto-vivification des rvalue ait lieu, alors qu'on s'attendrait à ce qu'elle n'ait pas lieu (selon le principe DWIM).
Tu peux ne pas répondre. C'est mon point de vue, et je ne t'oblige pas à le partager. La discussion a par ailleurs montré jusqu'à présent que tu ne m'as pas convaincu non plus, et j'ai des doutes que tu y parviennes encore à ce stade (de la conclusion).

Je ne cherche plus à te convaincre. Ce qui m'inquiète ici est que les seuls posts de ce fil à avoir reçu des votes positifs sont tes prétentions même pas assumées (je n'ai pas vu passer de bug report récent sur ce point) à faire considérer ce comportement comme un bug, et qui plus est en des termes qui frôlent la puérilité (magiquement démoniaque ? ).

La gestion de l'autovivification est une sorte de rite de passage à laquelle tout perlien est confronté tôt ou tard. Certains s'en sortent manifestement mieux que d'autres. Pour moi l'autovivification des Rvalues est une caractéristique de Perl5, de même que la non-autovivification des Rvalues est une caractéristique de Perl6 (j'ai vérifié). Une caractéristique, pas un bug, avec laquelle on doit vivre.

Par ailleurs, il me semble qu'aucun des palliatifs que tu proposes ne tient la route. Passons effectivement sur le fait de lever une exception sur head %$h quand $h est undef. Mais mettre par défaut no autovivification qw(fetch exists delete) ne vaut pas mieux à mon avis, car cela change la sémantique du langage.

Ce qui serait éventuellement acceptable selon moi, serait la mise en place d'un warning optionnel en cas d'autovivification de Rvalue. Ce n'est pas idéal, mais cela permettrait par exemple de faire passer une batterie de tests avec une option activant ce warning, pour ceux qui ne veulent effectivement pas d'autovivification de Rvalues. J'ai incidemment donné un exemple à mon avis tout à fait légitime d'autovivification de Rvalue, celui consistant à préallouer un tableau par accès en lecture à $aref->[$taille-1];

Il me semble en fait que l'autovivification d'éléments de tableaux est en pratique aussi dangereuse sinon plus que celle des hashes. Tu trouveras une analyse d'un exemple canonique de ce type d'occurrence ici (dans les paragraphes suivant 'Vers la version 6'). En résumé, l'auteur explore un tableau de caractères @car à partir de la position $k, et accède aux caractères en positions $k-1, $k+1, $k+2 sans aucun contrôle de la validité de ces indices. L'erreur réside dans cette absence de contrôle, pas dans l'autovivification des éléments (pour $k+1 et $k+2), ni dans l'accès à partir de la fin du tableau pour les indices négatifs (pour $k-1). Est-ce que tu voudrais aussi mettre hors la loi ces accès par la fin, sous prétexte qu'ils peuvent également s'avérer dangereux lorsqu'on ne les contrôle pas ?

Tu semble trouver bizarre que use strict; et use warnings; ne soient pas des options par défaut. Il y a des raisons historiques à cela, notamment le fait que depuis l'origine des programmeurs compétents écrivent du code parfaitement correct sans en avoir besoin. Ce sont des béquilles, rien de plus, et de plus leur activation n'est pas gratuite. Utilise-les si tu en as besoin mais s'il te plaît ne force pas tout le monde à faire de même. TIMTOWTDI.

Pour finir sur une note positive, je reconnais volontiers que pour les débutants ou certains programmeurs pressés ou sous pression, un warning tel que celui évoqué ci-dessus puisse être utile. Je pourrais même m'en servir à l'occasion. Son apparition serait selon moi une conséquence positive de cette discussion, et je serais prêt à appuyer une feature request en ce sens. Par contre je maintiens que les empoignades sur la qualification de l'autovivification de Rvalues comme un bug me paraissent stériles et contre-productives. Choisis ton camp .

[Lolo78]

Mes réserves de tact étant épuisées à ce stade

Il faut reconnaître qu'elles sont au départ particulièrement peu abondantes.

je maintiens que les empoignades sur la qualification de l'autovivification de Rvalues comme un bug me paraissent stériles et contre-productives. Choisis ton camp .

Et si je choisis celui de Tom Christiansen, brian de foy et Larry Wall (voir la citation que j'ai donnée précédemment), je suis un hérétique?

[cmcmc]

Mes réserves de tact étant épuisées à ce stade

Il faut reconnaître qu'elles sont au départ particulièrement peu abondantes.

C'est dans l’œil de l'observateur. J'ai pour ma part le sentiment d'avoir été poli, informatif et rigoureux. Jusqu'à un certain point, et pour les raisons que j'ai données.

je maintiens que les empoignades sur la qualification de l'autovivification de Rvalues comme un bug me paraissent stériles et contre-productives. Choisis ton camp .

Et si je choisis celui de Tom Christiansen, brian de foy et Larry Wall (voir la citation que j'ai donnée précédemment), je suis un hérétique?

On tourne en rond. J'ai déjà répondu plusieurs fois. Cette citation date d'avant 2000, nous sommes en 2013, ça devrait faire réfléchir... Quoi qu'il en soit, continue à considérer ce comportement comme un bug si tu veux mais par pitié fais quelque chose de positif. Si ces deux phrases sont tout ce que tu retiens de mon dernier post, alors effectivement il y a de quoi se taper la tête contre les murs.

[Lolo78]

Cette citation date d'avant 2000,

Certes, elle existait dans les éditions antérieures (du moins la troisième), mais je l'ai reprise de la quatrième édition, qui date de 2011 ou 2012. Larry, Tom et brian jugent manifestement qu'elle est toujours d'actualité.

Si ces deux phrases sont tout ce que tu retiens de mon dernier post, alors effectivement il y a de quoi se taper la tête contre les murs.

Je préfère ne pas retenir tes attaques personnelles et tes mises en doute de la compétence de tes interlocuteurs, que je mets sur le compte de l'échauffement de ton sang.

[Philou67430]

OK, passons sur l'exception

...]

...

Calembredaines.

J'aurais mieux fait de m'appliquer à moi-même mon conseil

... Ton discours, en revanche, était de contester l'inutilité de cette auto-vivification particulière, point sur lequel le fil entier pointe, et point sur lequel je souhaitais effectivement qu'il se concentre (qui sait, existe-t-il peut-être de vraies bonnes raisons à laisser en place un tel fonctionnement !DWIM).

Pas de révisionnisme, s'il te plaît. Dans mes premières réponses j'ai essayé d'élargir ta conception manifestement étroite de l'autovivification au cas des tableaux et même des scalaires, puis tenté de corriger ta conception erronée du mécanisme de l'autovivification. J'ai ensuite pointé l'existence de modules sur CPAN qui permettent de limiter les autovivifications "indésirables" ou leur impact, tout en indiquant clairement que ce n'est pas un problème pour tout le monde. J'ai enfin fait valoir que prétendre maintenant faire considérer comme un bug un comportement connu depuis l'origine de Perl me semblait un combat d'arrière garde, et de plus dépourvu d'impact sur la grande majorité des utilisateurs, qui utilisera de toute façon pendant longtemps des versions de Perl dépourvues de tout support ou correctif sur ce point.

Je ne vois pas ce qui dans la citation de mon message (notamment la partie surlignée) peut laisser penser que je réviserais ce que TU as dit. Je n'ai vu dans tes écrits aucun argument convaincant permettant de dire que l'auto-vivification de rvalue était souhaitable et utile.
Et par ailleurs, je ne crois pas avoir prétendu que je menais un combat contre ce que j'identifie comme une mauvaise spécification. Je voulais la partager, pas forcément convaincre. D'ailleurs, on ne combat plus une aussi vieille dame (compatibilité ascendante oblige), mais il est agréable de constater que l'idée que c'est un bug est confirmée par l'évolution apportée dans perl6 (postponed bug ?).

Mes réserves de tact étant épuisées à ce stade je vais écrire de manière probablement plus directe que je ne le devrais. Mon analyse de tes interventions sur ce fil est la suivante : suite à un bug dans ton code causé par ta propre méconnaissance du mécanisme de l'autovivification (malgré tes protestations du contraire), tu prétends exiger qu'un comportement que tu comprends mal soit considéré comme un bug de Perl. Effectivement, je refuse de te suivre dans cette voie.

Oui, forcément, ma connaissance de l'autovivification était incomplète, puisque je me suis fait avoir de bonne foi avec celle de ma référence non initialisée. Merci d'avoir développé les mécanismes (il faudrait que je reprenne la lecture du Camel un jour...).
Cela dit, le fait que l'on puisse considérer comme bug cette auto-vivification n'a rien a voir avec ma méconnaissance. Je considérais déjà avant cette nouvelle déconvenue que l'auto-vivification des rvalue était un bug.

J'ai déjà eu l'occasion d'en discuter il y a plusieurs années déjà, et à l'époque, c'était déjà un sujet bien polémique. Ca n'a pas vraiment évolué. Je persiste à penser que lorsqu'une spécification de langage apporte moins qu'elle ne dessert, c'est un bug (pas d'implémentation, mais de définition du langage). Le débat sur la correction, et si correction il doit y avoir est lui, tout autre, et dépend de beaucoup plus de paramètres. Je ne remets pas en cause que l'on garde ce statu quo pour perl5 (je ne crois pas l'avoir dit).

Ce qui était utile dans ton post initial était, comme je l'ai signalé, la mise en évidence d'une circonstance dans laquelle une autovivification inattendue pouvait se produire. J'aurai pu plusser pour ce seul point. Mais comme le reste du post m'amenait à moinsser, je n'ai rien fait.

Les plus ou moins, franchement, ce n'est pas le débat

La gestion de l'autovivification est une sorte de rite de passage à laquelle tout perlien est confronté tôt ou tard. Certains s'en sortent manifestement mieux que d'autres.

Personnellement, je m'en suis très bien sorti, le point est corrigé, et mémorisé : la prochaine fois que je verrai ce bug, je ne serai plus surpris (bug d'avoir laissé passer une auto-vivification que je ne souhaitais pas).

Pour moi l'autovivification des Rvalues est une caractéristique de Perl5, de même que la non-autovivification des Rvalues est une caractéristique de Perl6 (j'ai vérifié). Une caractéristique, pas un bug, avec laquelle on doit vivre.

Pour moi aussi... mais j'ajoute juste "malheureusement".
Mais comme je n'aime pas jeter le bébé avec l'eau du bain, je continuerai malgré tout à apprécier et (ab)user de perl.

Est-ce que tu voudrais aussi mettre hors la loi ces accès par la fin, sous prétexte qu'ils peuvent également s'avérer dangereux lorsqu'on ne les contrôle pas ?
Tu semble trouver bizarre que use strict; et use warnings; ne soient pas des options par défaut.

D'abord, c'est moi qui fait du révisionnisme, et maintenant, c'est toi qui revisite mes pensées... balle au centre ?

Il y a des raisons historiques à cela, notamment le fait que depuis l'origine des programmeurs compétents écrivent du code parfaitement correct sans en avoir besoin. Ce sont des béquilles, rien de plus, et de plus leur activation n'est pas gratuite. Utilise-les si tu en as besoin mais s'il te plaît ne force pas tout le monde à faire de même. TIMTOWTDI.

Je sais très bien à quoi servent "strict" et "warnings", même si je n'en connais pas forcément tous les détails. Ce que je sais avant tout, c'est qu'ils sont plus souvent des aides que des entraves. Donc l'idée de les préconiser (surtout aux débutants) me semble bonne.

Pour finir sur une note positive, je reconnais volontiers que pour les débutants ou certains programmeurs pressés ou sous pression, un warning tel que celui évoqué ci-dessus puisse être utile. Je pourrais même m'en servir à l'occasion. Son apparition serait selon moi une conséquence positive de cette discussion, et je serais prêt à appuyer une feature request en ce sens. Par contre je maintiens que les empoignades sur la qualification de l'autovivification de Rvalues comme un bug me paraissent stériles et contre-productives. Choisis ton camp .

Bien sûr qu'elles sont stériles ... il n'y a qu'à voir le contenu de cette discussion, et sa conclusion...
C'est d'ailleurs ce que je disais dès le premier message :

Je n'ai pas de question particulière, ...

Pour moi, à ce stade

Je ne cherchais éventuellement qu'une "bonne raison" qui permettrait d'invalider mon point de vue personnel... raison que je ne cherche plus aujourd'hui.

[cmcmc]

...balle au centre ?

Touché... Et balle au centre à raison et avec plaisir en ce qui me concerne.

+1 (parce que je ne peux pas faire mieux) pour le soin et la pondération apportée à ta réponse, il faut absolument que j'en prenne de la graine

Sur un sujet comme celui là ma véritable préoccupation est de déterminer comment aboutir à une issue par le haut, c'est à dire une évolution utile à tous sur ce qui effectivement est un vrai problème, et sans pour autant sacrifier l'existant. J'avais l'impression d'en avoir une ébauche avec le principe d'un warning optionnel, et j'aimerai sincèrement avoir ton avis (et celui d'autres s'ils veulent bien le communiquer) sur cette proposition avant éventuellement d'étudier sa faisabilité et d'en parler aux powers that be.

[Lolo78]

Un warning désactivable serait effectivement une excellente solution à mon humble avis; ça ne résoudrait pas tout, mais ça éviterait au moins de se faire prendre avec des bugs parfois bien difficiles à comprendre (au moins la première fois où ça m'est arrivé, j'ai eu du mal à trouver). Si tu connais des personnes "en haut lieu", alors vas-y, je ne peux qu'approuver.

[Philou67430]

Une warning désactivable (ou non) est une excellente solution. La solution d'exception que j'avais évoquée ne serait pas compatible avec les autres principes de perl, comme celui de ne pas lever d'exception lors de l'usage de undef (mais de soulever un warning).

[HS]
Quelque part, les warnings à l'exécution sont des exceptions non fatales. J'ai toujours aspiré à disposer d'un mécanisme du type eval { } pour les warnings, qui soit "cohérent" avec celui des exceptions (mêmes opérateurs, mêmes constructions). Peut-être trouve-t-on cela dans le CPAN, ou dans perl6... dommage que ce ne soit pas dans le core de perl5.
[/HS]

[cmcmc]

[HS]
Quelque part, les warnings à l'exécution sont des exceptions non fatales. J'ai toujours aspiré à disposer d'un mécanisme du type eval { } pour les warnings, qui soit "cohérent" avec celui des exceptions (mêmes opérateurs, mêmes constructions). Peut-être trouve-t-on cela dans le CPAN, ou dans perl6... dommage que ce ne soit pas dans le core de perl5.
[/HS]

Il me semble que ça y est... Tu peux modifier $SIG{__WARN__} pour spécifier le comportement que tu veux pour le traitement des warnings, avec une portée dynamique. Par exemple

Code x :

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

1
2
3
4
Taisha:~/tttmp $ perl -wE 'my $a; print $a; print qq{fin normale\n}'
Use of uninitialized value $a in print at -e line 1.
fin normale
Taisha:~/tttmp $

On transforme le warning en exception

Code x :

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

1
2
3
Taisha:~/tttmp $ perl -wE 'my $a; local $SIG{__WARN__} = sub { die qq{erreur : @_} }; print $a; print qq{fin normale\n}'
erreur : Use of uninitialized value $a in print at -e line 1.
Taisha:~/tttmp $

On peut attraper et traiter cette exception comme les autres

Code x :

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

1
2
3
4
Taisha:~/tttmp $ perl -wE 'my $a; eval { local $SIG{__WARN__} = sub { die qq{erreur : @_} }; print $a; 1} or do { my $e = $@; warn qq{traitement de $e} }; say qq{fin normale}'
traitement de erreur : Use of uninitialized value $a in print at -e line 1.
fin normale
Taisha:~/tttmp $

Pour une approche lexicale tu peux aussi regarder use warnings; dans perllexwarn :

Code x :

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

1
2
3
4
5
6
Taisha:~/tttmp $ perl -Mwarnings" FATAL=>qw(all)" -E 'my $a; print $a; say qq{fin normale}'
Use of uninitialized value $a in print at -e line 1.
Taisha:~/tttmp $ perl -Mwarnings" FATAL=>qw(all)" -E 'my $a; eval { print $a; 1} or do { my $e = $@; warn "traitement de $e" }; say qq{fin normale}'
traitement de Use of uninitialized value $a in print at -e line 1.
fin normale
Taisha:~/tttmp $

[cmcmc]

Un warning désactivable serait effectivement une excellente solution à mon humble avis; ça ne résoudrait pas tout, mais ça éviterait au moins de se faire prendre avec des bugs parfois bien difficiles à comprendre (au moins la première fois où ça m'est arrivé, j'ai eu du mal à trouver). Si tu connais des personnes "en haut lieu", alors vas-y, je ne peux qu'approuver.

Je ne connais personne "en haut lieu", par contre ce que j'ai pu vérifier c'est qu'un feature request accompagné d'un patch qui l'implémente a significativement plus de chances de passer qu'une simple requête

[Philou67430]

Il me semble que ça y est... Tu peux modifier $SIG{__WARN__} pour spécifier le comportement que tu veux pour le traitement des warnings, avec une portée dynamique.

Merci... j'ai oublié de préciser que je connais bien ce fonctionnement, et que c'est celui que j'utilise quand j'en ai besoin
Ca me semblait implicitement dit dans :

J'ai toujours aspiré à disposer d'un mécanisme du type eval { } pour les warnings, qui soit "cohérent" avec celui des exceptions (mêmes opérateurs, mêmes constructions)

Par exemple, un
eval { }
et une variable $WARNING_MSG qui capturerait le message de warning.
Merci d'avoir pensé aux autres lecteurs

Mais c'est un tout autre débat.