As BrowserUk said, autovivification is very useful most of the time. It is thanks to it that you can create directly a hash item such as:
$time{2016}{November}{03}{sales} = 2500;
even if $time{2016} (and, consequently, also $time{2016}{November}, and so on) does not exit yet.
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:
if(!defined $hash_ref->{$block}->{$libName}) {
print "This is a test\n";
}
to something like:
if(exists $hash_ref{$block} and !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).
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.
| 