in reply to Re^2: Unexpected exists() behavior
in thread Unexpected exists() behavior

It's not the function that is causing the key to be created as has been explained in this thread. Autovivification also allowed me to solve the problem at Migrating a 1NF table to multiple 2NF tables with more ease.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re^4: Unexpected exists() behavior
by Fletch (Bishop) on Jun 22, 2006 at 17:36 UTC

    That doesn't technically count as autovivification, though; that's undef being treated as 0 in a numeric context. Autovivification is the automatic creation of a reference to a new anonymous hash (or array) when required to implement a multilevel data structure.</pedant>

    Update: And to out pedant myself, you don't necessarily have to have a multilevel structure; my $aref; push @{ $aref }, 1; is autovivification as well. The Uri article referenced from the node I mentioned below uses the phrasing automatically creating a reference of the appropriate type whenever a scalar containing undef is dereferenced. Better than what I used above.

    Further update: The parent did have code using $hash{ $_ }++ and calling that autovivification. It's been removed so this now will make less sense. Ah well.