even if $time{2016} (and, consequently, also $time{2016}{November}, and so on) does not exit yet.$time{2016}{November}{03}{sales} = 2500;
Disabling autovivification might bring some bugs if your code is creating on the fly nested HoH items.
In some cases, of course, autovivification creates unwanted elements in a nested data structure, most notably when you check for the existence of a deeply nested element as in your example.
I would suggest that it is probably better to leave autovivification enabled and to perform your checks step by step, i.e. to change:
to something like:if(!defined $hash_ref->{$block}->{$libName}) { print "This is a test\n"; }
This will prevent $hash_ref->{$block} from springing into existence due to autovivification when this is unwanted, as in the case of an existence test such as the one you're doing. But you'll keep autovivification enabled when it is useful (i.e. in most cases).if(exists $hash_ref{$block} and !defined $hash_ref{$block}{$libName}) +{ print "This is a test\n"; }
To sum it up, it's not a bug, it's a feature. Although, to tell the truth, there could be a better middle way where autovivification would be enabled only when the nested reference appears in a Lvalue assignment statement. I think that the Camel book says something about it to the effect that it might be fixed one day but that it's not a priority; I was not able to find where, though, in the limited time I was ready to devote to this.
In reply to Re^3: Strange Hash related bug, keys are created by themselves!
by Laurent_R
in thread Strange Hash related bug, keys are created by themselves!
by mak007
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |