in reply to Re^3: multiple values for one key in hash
in thread multiple values for one key in hash

It doesn't work if there was an undef explicitly assigned to the value before. A lot of people get tripped up by this because they just assign undef to something they don't use anymore instead of deleting the key.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re^4: multiple values for one key in hash

Replies are listed 'Best First'.
Re^5: multiple values for one key in hash
by Fletch (Bishop) on May 13, 2008 at 01:55 UTC

    How would autovivification know that the undef in lvalue context it's autovivifying wasn't the original undef?

    $ perl -MYAML::Syck -le '$h{bar}=1;$h{bar}=undef;push @{$h{bar}}, qw/a + b c/;print Dump( \%h )' --- bar: - a - b - c

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

      How would autovivification know that the undef in lvalue context it's autovivifying wasn't the original undef?

      By using a proxy object that acts as undef. Note that you need a reference for autovivification anyway because push @{...} has to modify something that is stored in place of ... anyway.

      I don't know if Perl 5 does it that way, but I think kp6 does.

      huh. My understanding was always that an exists check was done in the background (reflecting my experience with the tied madness that is DBM::Deep), but I've never felt curious enough to explore more deeply.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?