glendeni has asked for the wisdom of the Perl Monks concerning the following question:

I'd always assumed tests could never _create_ anything - they were just tests that either succeeded or failed, never actually affecting variables solely by being used. So was very surprised to recently find that use of the 'defined' test on a hash of arrays ala 

defined $hash{$name}[$integer]

[download]

actually _created_ an empty $hash{$name} if $hash{$name} is non-existent, so is thereafter not non-existent.

Example code: 

  my %hash = ( "A" => [ 1,2 ] ) ;
  if ( exists  $hash{"B"}    ) { say "This will NOT print" ; }
  if ( defined $hash{"B"}[1] ) { say "This will NOT print" ; }
  if ( exists  $hash{"B"}    ) { say "This WILL print" ; }

[download]

So the "correct" test for existence of an array element in a hash of arrays should be 

  if ( exists $hash{"B"} && defined $hash{"B"}[1] )

[download]

Would appreciate comments by those with deeper knowledge of perl than I, since I can't see how such creation is in any way beneficial - rather it can introduce problems into a script, since the first use of such a test will fail but a second same test will later succeed without the programmer intending (or expecting) any such change.

IMHO a test should succed, or fail, or throw an error - period.

FYI the same occurs for a test ala "$#{$hash{"B"}} > -1".

Background: Have used perl regularly since 1998 so am experienced in perl, but never dug too deeply into it.

Replies are listed 'Best First'.
Re: Defined test creates non-empty hash value
by choroba (Cardinal) on Jun 12, 2024 at 16:40 UTC
    This behaviour of Perl is called "autovivification" and is documented in perlglossary and perlref.

    There's also a module to turn it off. Just start your code with 

    no autovivification;

    [download]
    See autovivification.

    Update: Fixed a typo, ThanX LanX.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
[select]
      Thanks for that. Have understood autovivification of variables when in assignment, increment, etc. but not realized it could affect a test. Googling on autovivification, I found in 'Perl Maven' blog, https://perlmaven.com/autovivification an example, with

      "This is quite unfortunate. This means we have changed the state of the %people has just by observing it. ... I think these undesirable cases are now generally considered to be a bug in Perl. Unfortunately it is very unlikely that this bug will be fixed in Perl 5 as there is a lot of code out in the wild (both on CPAN and in companies) that rely on this behavior. Correcting the behavior would break a lot of code."

      In the event, I am now wiser. Unfortunately, when creating some sparse hashs of arrays I do rely upon autovivification, with tests to identify their non-existence when necessary. But will now know how to adapt ...
[reply]

        Yes, this is one of those baked in historical oddities like every mature system has. You know, ones that, when you ask the original designer, the answer always starts with "It made sense at that time..."

        Those decisions might come back and bite you. But that doesn't mean the original designers made the wrong choice per se, they might just not have been able to see the whole picture that would result many years after they made their choices.

        Think of the Apollo 1 fire. It made sense for NASA to use a pure oxygen atmosphere in their capsules. It saved a lot of weight (weight is everything in rocketry) AND it made the capsules actually safer (no risk of accidentaly putting too much nitrogen in due to a bad sensor, suffocating the astronauts). It made sense to pressurize the capsules on the launch pad to test that they are not leaking away the precious air in space (reducing the risk of a Soyuz 11 catastrophe). It made sense to place Velcro strips all over the spacecraft interior to prevent objects floating around and messing up other systems (after all, in space under the normal, low O2 pressure, Velcro doesn't sustain fire).

        What nearly nobody realised were the consequences of the combination of all those factors. In the high, pure oxygen pressure during the plugs out test, Velcro doesn't just burn, it basically explodes. Gus, Ed and Roger paid the price. And yes, Apollo had an inward opening hatch that was presumable safer than the explosive hatch used on Gemini. It was engineered to prevent a repeat of the Gemini accident that nearly killed Gus. It's secured and doesn't open when the capsule is pressurized, just like the doors on modern airliners...

        So, defined() sometimes does autovivication and can give you a bad day. But i'm sure the original designers implemented it this way to prevent some problems they encountered at the time.

        PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
        Also check out my sisters artwork and my rather simple sketches/one-panel comics
[reply]
        > Unfortunately, when creating some sparse hashs of arrays I do rely upon autovivification

        no autovivification does pretty much what you (seem to) want, observation and reading is safe, but setting vivifies.

        Choroba already pointed you to autovivification

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery

[reply]
[d/l]
Re: Defined test creates non-empty hash value
by sectokia (Friar) on Jun 17, 2024 at 01:32 UTC

    There is more discussion about this here: https://www.perlmonks.org/?node_id=11151225 as this also caught me out.

    Most languages don't have autovivication which I think is why it catches so many people. My general thoughts on this is autovivication is overall more useful.

    Example: If you have a JSON structure in an object and you want to check if a certain item in the structure exists with a value, in javascript to avoid throwing an error it is extremely annoying:

    if (json && json.command && json.command.results && json.command.results[0] && json.command.results[0].code && (json.command.results[0].code == 9))

    But in perl with autovivificatin, its much nicer:

    if ($json->{command}{results}[0]{code}//0 == 9)
[reply]
[d/l]
[select]
      ...unless you didn't want to create the deeper structure. It's a bit swings and roundabouts!
[reply]

Back to Seekers of Perl Wisdom