SPUG: Slice of HashOfHash

DeRykus, Charles E charles.e.derykus at boeing.com
Thu Nov 16 10:29:55 PST 2006


... 
>>> for my $key ( qw[ flintstones jetsons jones simpsons ] ) {
>>>     if ( $HoH{ $key }{ husband } eq 'fred' ) {
>>>
>> probably better not to hardcode here:
>>  for my $hash ( @HoH{ keys %HoH } ) {
>>      if ( $hash->{ husband } eq 'fred' ) {

>you were right to warn about not hardcoding the keys above as if there
is a typo 
>in the above keys (eg s/jones/smith/) then a top level element would be
autovivified 
>(eg  $HoH{'smith'} = undef) but I suspect that the following advice is
wrong:

>> but the if statement is somewhat unsafe. in the case where the
subhash 
>> doesn't have a key named 'husband', it will be autovivified. this may

>> or may not be a problem.

>The above _may_ have been true at some version of perl (as I used to
write code like below also >(using exists) - but it is not now the case
when I test the code.  I you find a perl doing this >(where
>   if ( $hash->{ exhusband } eq 'fred' ) autovivifies some element in
%HoH), please let me know, > as I couldn't create a test case with
recent (6 year old) perl version where the if test needed > the exists
check that you gave below.

Although not directly relevant here, there's an arrow operator
autovivification
surprise mentioned in 'exists':

   undef $ref;
   if (exists $ref->{"Some key"})      { }
    print $ref;             # prints HASH(0x80d3d5c)

Although I couldn't conjure up an example, there might be a way to
get into trouble here if the top level HoH were a hash reference.

I recall a hideous bug where I had to adopt the exists doc workaround:

    if ( $ref                        and
         $ref->{$x}                  and
         $ref->{$x}{$y} ...

-- 
Charles DeRykus




More information about the spug-list mailing list