Discussion :

[Philou67430]

Bonjour à tous,

Je n'ai pas de question particulière, mais j'ai trouvé un bug dans un de mes programmes dû à une auto-vivification de hash à laquelle je ne m'attendais pas du tout. 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 :

Code :

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

1
2
3
my $hash; # contient undef
say keys %$hash; # pas d'erreur
say $hash; # contient {} (hash anonyme vide)

Pour moi, à ce stade, ce n'est plus une feature, c'est un bug (keys %$hash devrait lever une exception car $hash n'est pas une référence à un hash, comme il le fait si j'initialise my $hash = []).

Bonne journée à tous.

Code :

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

1
2
$ perl -E 'my $h;print $h // "UNDEF", " => ";keys %$h;$h and say $h // "UNDEF"'
UNDEF => HASH(0x8002bca8)

[6ril23]

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).

je sais pas si c'est fait exprès mais je trouve ça bon comme jeu de mot

[Philou67430]

Il n'est pas de moi. Certains dictionnaires connaissent bien ce mot : http://fr.wiktionary.org/wiki/automagiquement
Je crois que je l'ai lu la première fois d'un mongueur.

[cmcmc]

Pour moi, à ce stade, ce n'est plus une feature, c'est un bug (keys %$hash devrait lever une exception car $hash n'est pas une référence à un hash, comme il le fait si j'initialise my $hash = []).

Pourquoi donc ??? C'est extrêmement utile, et c'est indispensable à l'autovivification des éléments d'un hash ou d'un array:

Code :

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

1
2
3
4
5
6
my %hash;
push @{$hash{list}}, whatever; # autovivification de $hash{list}
${hash}{scalaire} = whatever;  # autovivification de $hash{scalaire}
${hash}{a}{b}{c} = whatever;   # autovivification de $hash{a} (en hashref), $hash{a}{b} (en hashref), $hash{a}{b}{c} (en scalaire)
my @array;
$array[9] = whatever;          # autovivification du 10 eme element de @array

Un scalaire naît non typé, et le reste tant qu'il est undef. C'est son utilisation qui lui donne (temporairement) un type.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Taisha:~/tttmp $ perl -Mstrict -MData::Dumper -E 'my $h; for (q{123}, q{[1,2,3]}, q/{1, 2, 3, 4}/, q{qr/123/}, q|sub { 123 }|) { my $f = "\$h = $_"; eval $f; print sprintf("%-20s ---> ref(\$h) = %-10s", $f, ("\"".ref($h)."\"")), Dumper($h)}'
$h = 123             ---> ref($h) = ""        $VAR1 = 123;
$h = [1,2,3]         ---> ref($h) = "ARRAY"   $VAR1 = [
          1,
          2,
          3
        ];
$h = {1, 2, 3, 4}    ---> ref($h) = "HASH"    $VAR1 = {
          '1' => 2,
          '3' => 4
        };
$h = qr/123/         ---> ref($h) = "Regexp"  $VAR1 = qr/(?^u:123)/;
$h = sub { 123 }     ---> ref($h) = "CODE"    $VAR1 = sub { "DUMMY" };
Taisha:~/tttmp $

Dès lors que tu opères (même indirectement) sur %$h tu indiques ton intention d'utiliser $h comme une référence à un hash. De la même manière, si tu opères sur @$h; tu en fais une référence à un tableau:

Code :

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

1
2
3
4
Taisha:~/tttmp $ perl -Mstrict -MData::Dumper -E 'my $h; say shift(@$h); print Dumper($h)'
 
$VAR1 = [];
Taisha:~/tttmp $

La forme suivante est classique pour préallouer un tableau (ici 10 éléments) sans l'initialiser

Code :

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

1
2
3
Taisha:~/tttmp $ perl -Mstrict -MData::Dumper -E 'my $h; $h->[9]; print Dumper($h)'
$VAR1 = [];
Taisha:~/tttmp $

Ces opérations échouent avec une exception uniquement si la référence en question est déjà initialisée à un type non compatible :

Code :

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

1
2
3
4
5
Taisha:~/tttmp $ perl -Mstrict -MData::Dumper -E 'my $h; $h = 1234; say shift(@$h); print Dumper($h)'
Can't use string ("1234") as an ARRAY ref while "strict refs" in use at -e line 1.
Taisha:~/tttmp $ perl -Mstrict -MData::Dumper -E 'my $h; $h = 1234; say keys(%$h); print Dumper($h)'
Can't use string ("1234") as a HASH ref while "strict refs" in use at -e line 1.
Taisha:~/tttmp $

En résumé, si tu veux te protéger contre de telles autovivifications, c'est à toi d'initialiser explicitement les variables qui ne doivent pas l'être, par exemple

Code :

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

1
2
3
4
5
Taisha:~/tttmp $ perl -Mstrict -E 'use constant NIL => \0; my $h = NIL; keys %$h'
Not a HASH reference at -e line 1.
Taisha:~/tttmp $ perl -Mstrict -E 'use constant NIL => \0; my $h = NIL; shift @$h'
Not an ARRAY reference at -e line 1.
Taisha:~/tttmp $

[cmcmc]

je sais pas si c'est fait exprès mais je trouve ça bon comme jeu de mot

Moi aussi , bien que ce soit un peu trompeur car Magic a une signification technique précise en Perl

[Philou67430]

Pourquoi donc ??? C'est extrêmement utile, et c'est indispensable à l'autovivification des éléments d'un hash ou d'un array

Je n'ai pas dit que je ne connaissait pas l'auto-vivification des éléments d'un hash (ou d'un array), ni que j'ignorais leur intérêt.

J'ai parlé du cas particulier où l'appel à "keys %$h" auto-vivifiait un hash vide (et ne permettait donc plus, à postériori, de vérifier si cette référence était définie ou non).

Dès lors que tu opères (même indirectement) sur %$h tu indiques ton intention d'utiliser $h comme une référence à un hash.

Cela dépend de ce que l'on entends pas "opérer" : certains opérateur n'auto-vivifient pas, et certains oui.

Comme expliqué ici, l'auto-vivification doit avoir lieu lorsque la référence est utilisée en tant que lvalue. Ainsi :

Code :

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

1
2
3
$ perl -wE 'my $h;print $h // "UNDEF", " => ";() = %$h;say $h // "UNDEF"'
Use of uninitialized value $h in hash dereference at -e line 1.
UNDEF => UNDEF

et par contre

Code :

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

1
2
$ perl -wE 'my $h;print $h // "UNDEF", " => ";%$h = ();say $h // "UNDEF"'
UNDEF => HASH(0x8002bca8)

Ce que j'admets parfaitement.

En revanche, les utilisations comme celle-ci :

Code :

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

1
2
3
4
$ perl -wE 'my $h;print $h // "UNDEF", " => ";keys(%$h);say $h // "UNDEF"'
UNDEF => HASH(0x8002bca8)
$ perl -wE 'my $h;print $h // "UNDEF", " => ";exists($h->{toto});say $h // "UNDEF"'
UNDEF => HASH(0x8002bca8)

Ne devrait pas fournir un contexte de lvalue à la référence, et ainsi, créer une référence de hash vide.

Je connaissais ce bug pour exists, mais pas encore pour keys.

Selon mon point de vue, l'auto-vivification est une feature qui ne devrait s'appliquer que dans un contexte "d'affectation de valeur" et pas dans un contexte d'utilisation, parce que j'estime que le gain dans ce cas ne compense pas les pertes.
De même, elle devrait se limiter à créer les clés intermédiaires. Or, dans le cas de keys(%$h) il n'y a aucune clé intermédiaire manquante, l'auto-vivification ne devrait pas avoir lieu également pour cette raison. Quand à son usage avec exists, qui cherche justement à vérifier l'existence d'une clé, l'auto-vivification devrait être bannie.

[cmcmc]

Comme expliqué ici, l'auto-vivification doit avoir lieu lorsque la référence est utilisée en tant que lvalue.

Non . Ce n'est pas parce que c'est écrit dans perlmonks que ça fait autorité. En l'occurrence c'est faux. L'autovivification se produit lorsqu'on déréférence une variable ou référence non définie, que ça soit en lecture ou en écriture. Mon exemple sur l'autovivification d'un tableau sur une lecture le montre bien,

Code :

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

1
2
3
Taisha:~/tttmp $ perl -Mstrict -MData::Dumper -E 'my $h; my $a = $h->[100]; print Dumper($h)'
$VAR1 = [];
Taisha:~/tttmp $

Cela montre par ailleurs que ce n'est pas limité aux hashes. En fait dans l'exemple ci-dessous

Code :

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

1
2
3
Taisha:~/tttmp $ perl -Mstrict -MData::Dumper -E 'my $h; ${$h} = q{cible}; print Dumper($h)' 1
$VAR1 = \'cible';
Taisha:~/tttmp $

La variable indéfinie $h est transformée en référence scalaire. Ce n'est pas tout à fait une autovivification mais c'est proche, et en particulier ça échoue de la même manière que pour l'autovivification de tableaux ou de hashes :

Code :

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

1
2
3
Taisha:~/tttmp $ perl -Mstrict -MData::Dumper -E 'my $h = []; ${$h} = q{cible}; print Dumper($h)' 1
Not a SCALAR reference at -e line 1.
Taisha:~/tttmp $

Quoi qu'il en soit, et en pratique, on peut prévenir certaines autovivifications en travaillant sur un restricted hash, en utilisant Data::Diver, ou le pragma lexical autovivification du CPAN, etc.

Par exemple, avec le pragma lexical autovivification :

• pas d'autovivification par keys

  Code :

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

  1
  2
  3
  4
  5
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; my $f = q{keys %$h}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)'
  $VAR1 = {};
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; my $f = q{keys %$h}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)' 1
  $VAR1 = undef;
  Taisha:~/tttmp $

• là non plus
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; my $f = q{keys $h->{a}{b}{c}}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)'
  $VAR1 = {
            'a' => {
                     'b' => {}
                   }
          };
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; my $f = q{keys $h->{a}{b}{c}}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)' 1
  $VAR1 = undef;
  Taisha:~/tttmp $

• pas de création de la clé $h{a}{c}
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; $h->{a}{b} = 0; my $f = q{$h->{c}{d}}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)'
  $VAR1 = {
            'c' => {},
            'a' => {
                     'b' => 0
                   }
          };
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; $h->{a}{b} = 0; my $f = q{$h->{c}{d}}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)' 1
  $VAR1 = {
            'a' => {
                     'b' => 0
                   }
          };
  Taisha:~/tttmp $

• pas d'autovivification en tableau
  

  Code :

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

  1
  2
  3
  4
  5
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; my $f = q{$h->[0]}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)'
  $VAR1 = [];
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; my $f = q{$h->[0]}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)' 1
  $VAR1 = undef;
  Taisha:~/tttmp $

• là non plus
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; my $f = q{$h->[3][4][2]}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)'
  $VAR1 = [
            undef,
            undef,
            undef,
            [
              undef,
              undef,
              undef,
              undef,
              []
            ]
          ];
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'my $h; my $f = q{$h->[3][4][2]}; if (@ARGV) {no autovivification; eval $f} else {eval $f}; print Dumper($h)' 1
  $VAR1 = undef;
  Taisha:~/tttmp $

... Quand à son usage avec exists, qui cherche justement à vérifier l'existence d'une clé, l'auto-vivification devrait être bannie.

Ca a été considéré (idem pour defined) pour Perl6, je ne sais pas si ça a été finalement retenu. Mais pour Perl5 il me semble que les outils suffisants existent déjà pour prévenir les autovivifications accidentelles. Ceci dit, si tu y tiens, rien ne t'empêche d'envoyer un bug report (ou une feature request) via perlbug, tu verras bien comment c'est reçu...

[cmcmc]

Ceci dit, si tu y tiens, rien ne t'empêche d'envoyer un bug report (ou une feature request) via perlbug, tu verras bien comment c'est reçu...

pour info, un échange sur p5p datant de 1997 sur ce même thème...

[Philou67430]

Je me fiche bien de savoir comment annuler l'auto-vivification... puisque je veux en profiter dans la plupart des cas. Mais je souhaiterais qu'elle se comporte magiquement comme on pourrait s'y attendre, c'est à dire sans auto-vivifier avec exists (et keys), afin notamment d'éviter les travers liés à une auto-vivification non désirée.

Si ce n'est pas dans l'esprit de perl, alors je naviguerai à contre-courant, parce que mon objectif n'est pas de satisfaire les concepteurs de perl, mais de satisfaire mes besoins.

[cmcmc]

Quoi qu'il en soit, et en pratique, on peut prévenir certaines autovivifications en travaillant sur un restricted hash, en utilisant Data::Diver, ou le pragma lexical autovivification du CPAN, etc.

... et je me rends compte que perlfaq4 semble d'accord , ça m'apprendra à vérifier avant de poster, j'aurais gagné du temps

[cmcmc]

Je me fiche bien de savoir comment annuler l'auto-vivification... puisque je veux en profiter dans la plupart des cas. Mais je souhaiterais qu'elle se comporte magiquement comme on pourrait s'y attendre, c'est à dire sans auto-vivifier avec exists (et keys), afin notamment d'éviter les travers liés à une auto-vivification non désirée.

tu aurais pu jeter un coup d'oeil sur les liens indiqués . Il me semble que ton besoin est couvert par

Code :

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

no autovivification qw(fetch exists);

• on peut assigner les clés ...
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'no autovivification qw(fetch exists); my $h; @{$h}{qw/1 2 3/} = qw/a b c/; print Dumper($h)'
  $VAR1 = {
            '1' => 'a',
            '3' => 'c',
            '2' => 'b'
          };
  Taisha:~/tttmp $

• ... mais pas d'autovivification par keys
  

  Code :

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

  1
  2
  3
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'no autovivification qw(fetch exists); my $h; keys %$h; print Dumper($h)'
  $VAR1 = undef;
  Taisha:~/tttmp $

• autovivification profonde en écriture...
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'no autovivification qw(fetch exists); my $h; $h->{a}{b}{c} = 0; print Dumper($h)'
  $VAR1 = {
            'a' => {
                     'b' => {
                              'c' => 0
                            }
                   }
          };
  Taisha:~/tttmp $

• ... mais pas en lecture
  

  Code :

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

  1
  2
  3
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'no autovivification qw(fetch exists); my $h; my $a = $h->{a}{b}{c}; print Dumper($h)'
  $VAR1 = undef;
  Taisha:~/tttmp $

• pas d'autovivification par exists
  

  Code :

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

  1
  2
  3
  Taisha:~/tttmp $ perl -Mstrict -Mautovivification -MData::Dumper -E 'no autovivification qw(fetch exists); my $h; my $a = exists $h->{a}{b}{c}; print Dumper($h)'
  $VAR1 = undef;
  Taisha:~/tttmp $

bon, je te laisse explorer...

Si ce n'est pas dans l'esprit de perl, alors je naviguerai à contre-courant, parce que mon objectif n'est pas de satisfaire les concepteurs de perl, mais de satisfaire mes besoins.

TIMTOWTDI. Je crois que tu n'imagines pas à quel point les concepteurs de perl s'attachent à fournir les moyens de satisfaire tes besoins (et ceux de millions d'autres).

[Lolo78]

Citation du Camel Book (Programming Perl, 4th Edition):

This is one of those cases mentioned earlier in which references spring into existence (or “autovivify”) when used as an lvalue (that is, when a value is being assigned to it). If $array[3] was undefined, it’s automatically defined as a hash reference so that we can set a value for $array[3]–>{"English"} in it. Once that’s done, $array[3]–>{"English"} is automatically defined as an array reference so that we can assign something to the first element in that array. Note that rvalues are a little different: print $array[3]–>{"English"}–>[0] only defines $array[3] and $array[3]–>{"English"}, not $array[3]–>{"English"}–>[0], since the final element is not an lvalue. (The fact that it defines the first two at all in an rvalue context could be considered a bug. We may fix that someday.)

(C'est moi qui souligne la dernière phrase.)

Si Larry Wall, Tom Christiansen et brian de foy le reconnaissent eux-mêmes...

[cmcmc]

Il me semble que ton besoin est couvert par

Code :

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

no autovivification qw(fetch exists);

En fait comme tu voudras probablement aussi delete, le défaut

Code :

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

no autovivification;

identique à

Code :

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

no autovivification qw(fetch exists delete);

est probablement approprié.

We may fix that someday.

Si Larry Wall, Tom Christiansen et brian de foy le reconnaissent eux-mêmes...

Et quel est ton point exactement ?

Un module CPAN est une solution, parfaitement reconnue et acceptée par Larry, Tom et Brian... Perl est distribué avec des modules dont la version upstream est sur CPAN. Le fait qu'un module ne soit pas dans la distribution n'indique pas qu'il soit de qualité ou d'intérêt inférieurs. En fait il y a un effort en ce moment pour extraire de la distribution standard des modules qui n'ont pas de raison effective d'y résider.

Les développeurs de Perl prennent les problèmes de compatibilité arrière très au sérieux. Si par exemple exists devait être modifiée pour ne plus autovivifier les clés intermédiaires inexistantes en cas d'accès profond, cela ne pourraît être de toute façon que sous le contrôle d'un use feature '...'.

Et même si le comportement d'exists était modifié, il ne le serait qu'à partir de Perl20.0 au plus tôt. Combien de gens sont obligés de travailler avec des versions antérieures ? Le pragma autovivification tourne sur les versions 5.8.3 et suivantes...

[Lolo78]

Et quel est ton point exactement ?

Que Larry, Tom et accessoirement brian reconnaissent que c'était probablement un mauvais choix ou une erreur d'implémentation.

C'est aussi mon avis et celui de Philou.

Ce genre d'erreur peut arriver, on ne va pas en faire une montagne non plus.

Mais c'est quand même un vrai problème. Nie l'évidence si ça te plaît, mais c'est pourtant une réalité.

Alors, oui, on peut contourner le problème, avec des modules, etc. Mais encore faut-il connaître leur existence et ça ne change pas la réalité du problème, le Core Perl est bugué sur cet aspect. Et puis je ne connais pas ces modules, mais l'autovivification est une excellente chose la plupart du temps (sur les Lvalues) mais pas dans le cas des Rvalues, je ne veux certainement pas la désactiver systématiquement .

Le problème est là, c'est indéniable et c'est une vraie bêtise. Je ne comprends même pas ton acharnement à le nier.

J'adore Perl, parce qu'il est vraiment très bon. Mais quand, exceptionnellement, il est moins bon, voire mauvais, je ne vois aucune raison de le nier. Je préférerais qu'il s'améliore sur ces rares points.
[/QUOTE]

[cmcmc]

Que Larry, Tom et accessoirement brian reconnaissent que c'était probablement un mauvais choix ou une erreur d'implémentation.

Pourquoi capitaliser Larry et Tom et pas Brian ?

C'est aussi mon avis et celui de Philou.

Ce genre d'erreur peut arriver, on ne va pas en faire une montagne non plus.

Mais c'est quand même un vrai problème. Nie l'évidence si ça te plaît, mais c'est pourtant une réalité.

Pour moi l'évidence en l'occurrence est double :

1. ce n'est pas un problème pour tout le monde
2. pour ceux pour qui c'est un problème, des solutions sont listées dans la FAQ officielle, qui fait partie de la documentation

Alors, oui, on peut contourner le problème, avec des modules, etc. Mais encore faut-il connaître leur existence et ça ne change pas la réalité du problème, le Core Perl est bugué sur cet aspect. Et puis je ne connais pas ces modules, mais l'autovivification est une excellente chose la plupart du temps (sur les Lvalues) mais pas dans le cas des Rvalues, je ne veux certainement pas la désactiver systématiquement .

Qui te parle de la désactiver systématiquement ? Fais connaissance avec ces modules, comme la doc te le recommande. Pour le pragma autovivification :

1. Rvalues vs. Lvalues : regarde les options possibles pour no autovivification
   
   • fetch
   • store
   • exists
   • delete
   
   et mets les en correspondance avec tes concepts de Rvalue et Lvalue, ça devrait matcher sans trop de difficultés...
2. Systématiquement : c'est un pragma lexical. On fait difficilement plus souple.

Et ce pragma n'est qu'une solution parmi d'autres.

Le problème est là, c'est indéniable et c'est une vraie bêtise. Je ne comprends même pas ton acharnement à le nier.

Il me semble que je m'acharne surtout à corriger des erreurs factuelles et à pointer des solutions...

Je ne nie rien du tout. J'admets parfaitement que cela puisse poser des problèmes à certains. Ca m'en a posé il y a longtemps. Plus maintenant, probablement parce que j'ai adapté (peut-être plus ou moins inconsciemment) mes pratiques de codage en conséquence. Le pragma autovivification ne m'était pas venu spontanément en tête suite au message initial de Philou67430, c'est dire.

Que ça soit une bêtise ou pas, il faut vivre avec et le point important est que des outils documentés existent pour ça.

J'adore Perl, parce qu'il est vraiment très bon. Mais quand, exceptionnellement, il est moins bon, voire mauvais, je ne vois aucune raison de le nier.

Le paragraphe du Camel que tu cites figurait dans la troisième édition de 2000 (je ne retrouve plus la seconde édition ). J'ai donné un exemple d'échange datant de 1997 dans lequel l'opinion suivante est exprimée comme une évidence : autovivification in rvalue contexts is a bug. Qu'est ce que tu crois ? Que personne ne s'est intéressé au problème depuis tout ce temps ? Si ça n'a pas été résolu à ta satisfaction (ou celle de Philou67430), est-ce que tu peux imaginer que ça puisse être pour des raisons sérieuses et importantes, de celles qui font que tu peux continuer à utiliser Perl sur de nouvelles architectures, de nouveaux systèmes, etc ?

Je préférerais qu'il s'améliore sur ces rares points.

Ce n'est pas impossible, mais une fois de plus ce sera largement académique pour la très grande majorité des utilisateurs de Perl, qui sont sur des versions souvent très en retard par rapport aux dernières sorties, ou doivent produire du code exécutable sur ces versions. Le dernier Linux que j'ai installé chez moi comme image de conf client était un CentoS 6.3 avec un perl en version 5.10...

Pour mon propre code et celui de ma boîte je compile moi même mes perls donc je fais ce que je veux. Mais pour produire du code pour des clients, qui tourne avec leurs antiquités, je suis obligé de me passer de say, de //, de s///r, et bien d'autres. J'ai corrigé des bugs de Perl, et ça ne me sert à rien quand je dois cibler les antiquités précitées.

Mais je pourrais utiliser le pragma autovivification si j'en éprouvais le besoin.

[Lolo78]

Pourquoi capitaliser Larry et Tom et pas Brian ?

Parce que brian de foy écrit systématiquement son nom en caractères bas de casse, sans capitales initiales, que ce soit dans ses contributions à la FAQ Perl, son site, ses articles ou ses livres. Tu peux le vérifier sur cette page, par exemple.

Pour moi l'évidence en l'occurrence est double :

1. ce n'est pas un problème pour tout le monde
2. pour ceux pour qui c'est un problème, des solutions sont listées dans la FAQ officielle, qui fait partie de la documentation

Bien sûr qu'il existe des solutions, mais le fait qu'il existe des solutions n'empêche pas que ce soit un problème. A peu près toute personne ayant utilisé un jour des structures de données imbriquées s'est fait avoir un jour ou l'autre par ce comportement n'ayant par ailleurs aucune utilité.

Le paragraphe du Camel que tu cites figurait dans la troisième édition de 2000.

Je sais bien, j'en ai la version française sur mon bureau.

Qu'est ce que tu crois ? Que personne ne s'est intéressé au problème depuis tout ce temps ? Si ça n'a pas été résolu à ta satisfaction (ou celle de Philou67430), est-ce que tu peux imaginer que ça puisse être pour des raisons sérieuses et importantes, de celles qui font que tu peux continuer à utiliser Perl sur de nouvelles architectures, de nouveaux systèmes, etc ?

C'est ce bug qui permet d'utiliser Perl sur de nouvelles architectures? Dans ce cas, évidemment, il ne faut surtout pas souhaiter d'améliorations...

Ce n'est pas impossible, mais une fois de plus ce sera largement académique pour la très grande majorité des utilisateurs de Perl, qui sont sur des versions souvent très en retard par rapport aux dernières sorties, ou doivent produire du code exécutable sur ces versions. Le dernier Linux que j'ai installé chez moi comme image de conf client était un CentoS 6.3 avec un perl en version 5.10...

Et je suis en 5.8 sur trois des bécanes que j'utilise le plus au bureau et la quatième vient il y a juste quelques mois de migrer en 5.10 (la plus récente disponible pour la version d'AIX concernée). Mais cela ne m'empêche nullement de souhaiter des améliorations, même si je sais que je n'en bénéficierai pas dans l'immédiat.

L'une des forces de Perl à mes yeux est son aspect DWIM (do what I mean). Je trouce cela dommage quand ce principe n'est pas respecté, même si je peux vivre avec.

[cmcmc]

Parce que brian de foy écrit systématiquement son nom en caractères bas de casse, sans capitales initiales, que ce soit dans ses contributions à la FAQ Perl, son site, ses articles ou ses livres. Tu peux le vérifier sur cette page, par exemple.

Merci, +1.

C'est ce bug qui permet d'utiliser Perl sur de nouvelles architectures? Dans ce cas, évidemment, il ne faut surtout pas souhaiter d'améliorations...

Non, il est normal et sain de souhaiter des améliorations. Une fois de plus, envoyez si vous le désirez un bug report ou une feature request aux développeurs. Ou, mieux encore, prenez le problème à bras le corps et apportez votre contribution : au moment ou j'écris ces lignes, perltodo mentionne toujours

728 =head2 autovivification
729
730 Make all autovivification consistent w.r.t LVALUE/RVALUE and strict/no strict;
731
732 This task is incremental - even a little bit of work on it will help.

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... A défaut, une feature request permettrait sans doute d'avoir une réponse "officielle" sur leurs plans en ce domaine -- ou absence de plans, s'ils considèrent par exemple que le pragma autovivification est la réponse canonique, ce que pour ma part je me garde bien d'affirmer à ce stade.

L'une des forces de Perl à mes yeux est son aspect DWIM (do what I mean). Je trouce cela dommage quand ce principe n'est pas respecté, même si je peux vivre avec.

Amen, et j'admets volontiers que mon propre WIM puisse parfois différer de celui de mon voisin

En synthèse, Philou67430 a eu tout a fait raison de mettre en évidence une circonstance dans laquelle une autovivification inattendue pouvait se produire. C'est utile. J'espère de mon côté que, indépendamment des empoignades sur le fait que ce soit un bug ou pas, mes propres indications seront utiles également.

Bonne journée

[Philou67430]

Il y a plusieurs problèmes avec le pragma "autovivification" :
- il n'est pas fourni dans le Core perl, ce qui peut paraitre étrange également
- le pragma ne traite pas tous les cas (voir CAVEATS)
- il faudrait, pour éviter les problèmes liés aux mauvaises auto-vivification (qui sont par ailleurs "sans utilité") systématiquement intégrer "no autovivification" dans les scripts, à la manière de "use strict" et "use warnings"... quand qqchose devient systématique, on peut se demander pourquoi ce n'est pas l'option par défaut.

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.

PS : Il me semble, mais je n'en suis pas sûr, qu'il existe déjà un bug perl enregistré au sujet des auto-vivification non désirées.

[cmcmc]

... 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.

Ce que tu demandais surtout dans ton premier post était que keys %$h lève une exception, rien que ça, si $h était undef. Ce que tu peux espérer au mieux est que keys %$h retourne undef et n'autovivifie par $h.

[Philou67430]

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 (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).
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). 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).