http://www.perlmonks.org?node_id=1012831


in reply to Undesirable parent hash keys

Do you really have an autovivification problem?

> I only want to be here if I set $Hash{'2013'}{'Oct'}{'11th'} = 1 explicitly.

If you only check  if ($Hash{'2013'}{'Oct'}{'11th'} == 1) { .. } you can't be bothered by hash-refs.

Anyway better rethink your concept!

When setting $Hash{'2013'}{'Oct'}{'11th'} = 1 you are overwriting a potential hashref to a nested hash and any previous $Hash{'2013'}{'Oct'}{'11th'}{'1AM'}{'30Min'}=1 will be lost.

Better use an additional level of keys to mark and write and test $Hash{'2013'}{'Oct'}{'11th'}{MARK} or so.

Cheers Rolf

Replies are listed 'Best First'.
Re^2: Undesirable parent hash keys (concept?)
by sophate (Beadle) on Jan 11, 2013 at 09:26 UTC

    sorry for the confusion. the examaple i gave wasn't perfect. what i wanted to say is 

      ## I only want to be here if I set
  ## $Hash{'2013'}{'Oct'}{'11th'} 
  ## or $Hash{'2013'}{'Oct'}{'11th'}{...}...{...}
  ## explicitly.

    [download]
[reply]
[d/l]
      Then the only practical solution is to switch off autovivification. But take care to do it only in a limited scope because many other modules may still need it and could break unexpectedly if it is switched off.;

      It is probably more safe to do a no autovivification 'exists'; as this turns off autovivification for dereferencing expressions that are parts of an exists only, such as : 

      exists $arrayref->[1][2][$idx]
exists $hashref->{this}{that}{$key};

      [download]
      and then make sure you change your tests to include the exists function.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      My blog: Imperial Deltronics
[reply]
[d/l]
[select]

        autovivification has lexical scope, so if other modules rely on autovivification, then using no autovivification in your script/module shouldn't harm them. (The only exception I could think of would be modules that play with B::Hooks::Parser, etc, to do weird stuff within your lexical scope.)

        I don't see much value in explicitly specifying the 'exists' option for the autovivification pragma, as the default options are pretty sane: when no autovivification is in effect, autovivification will still be allowed for "store" operations...

        use strict;
use warnings;
no autovivification;  # default options

use Data::Dumper;

my $ref = undef;
$ref->{foo}[0]{bar}[0] = 42;  # store
print Dumper $ref;

        [download]
        perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom