You are actually creating a symbolic reference, creating a new hash named "Apple" in the case of:

$hash{'food'} = 'Apple';
$hash{'food'}{'color'} = 'Red';
print "$hash{food}{color}\n";
print "$Apple{color}\n";
[download]

This might be more apparent if you look at the dereference in this manner:

$hash{'food'} = 'Apple';
${$hash{'food'}}{'color'} = 'Red';
print "$hash{food}{color}\n";
print "$Apple{color}\n";
[download]

You can see that you are using a string as a reference. However, in the following situation:

$hash{food}{color} = 'Red';
$hash{food} = 'Apple';
[download]

Because $hash{food} is undefined, Perl autovivifies the hash reference and stores it as the value for the key 'food'. The next line simply overwrites that value with the string 'Apple'. The key is knowing that Perl only autovivifies when you dereference an undefined value as a reference. Then we get to your final example:

$hash1{'food'} = 'Apple';
$hash1{'food'}{'color'} = 'Red';

$hash2{'food'}{'color'} = 'Red';
$hash2{'food'} = 'Apple';

print "hash1: $hash1{'food'}{'color'} $hash1{'food'}\n";
print "hash2: $hash2{'food'}{'color'} $hash2{'food'}\n";
[download]

And one hash is mysteriously affecting another --- but really, your the second statement result in a symbolic reference to a hash %Apple with a key 'color' and value 'Red'. The first hash2 assignment does autovivify a real hash reference, but that is overwritten in the second hash2 assignment. When you print out hash2, the first value is actually dereferencing the symbolic %Apple hash, just like before. This kind of confusion is a good reason to *not* use symbolic references and to always use 'strict'.

Somehow I think you're not using strict.

On my machine $hash{ 'key1' }{ 'key2' } gives me a compilation time error with strict

Perhaps you meant $hash{ 'key1' }->{ 'key2' } ?

Either way, do this to verify if your hashes are working the way you want them to...

      use Data::Dumper;
      print Dumper( \%hash );
[download]

This is quick and dirty, but at least you get to do a sanity check as to what's in the hash...

----

update: added explanation in a separate node upon request :)

update: a few people have gotten me. for those of you reading my posts in this thread, please make sure to read these two posts, cause I screwed up. :(

Perhaps you meant $hash{ 'key1' }->{ 'key2' } ?

Care to continue that thought with an explaination of how

$hash{ 'key1' }->{ 'key2' }
[download]

is different in meaning from

$hash{ 'key1' }{ 'key2' }
[download]

?

As everybody else says,

     $hash{ 'key1' }{ 'key2' }
[download]

takes the contents of $hash{ 'key1' } to be a symbolic reference, and then tries to get the value of that corresponds to 'key2' against a hash with the name = $hash{ 'key1' }

So

     $hash{ 'key1' } = 'foo';
     $hash{ 'key1' }{ 'key2' } = 'bar'; # (2)

     # (2) means find %(current pkg)::foo and do
     $(current pkg)::foo{ 'key2' } = 'bar';
[download]

Still a hash of hashes, but I find this rather tricky to use. You always have to be aware of the fact that $hash{ 'key1' }{ 'key2' } is being evaluated via symbols

However, $hash{ 'key1' }->{ 'key2' } would be used like this:

     my %hash;
     $hash{ 'key1' } = {}; ## ref to hash

     $hash{ 'key1' }->{ 'key2' } = 'foo';

     ## above equivalent to
     my %hash = (
           key1 => {
                  key2 => 'foo'
           }
     );
[download]

And, of course, I wrote up to here and realized that it doesn't really fit to the original problem! sigh.

I probably should have pointed to

       $hash{ 'key1' } = 'foo';
       $hash{ 'key1', 'key2' } = 'bar';
[download]

But I really dislike that notation. ( and the way things gets stored when you do it that way )

As for the original problem, I would have done:

       my %hash = (
             food => {
                   name => 'Apple',
                   color => 'Red'
             }
       );

       my $food = $hash{ 'food' };
       print "$food->{ 'color' } $food->{ 'name' }\n";
[download]

Is this explanation better ? :-)

Now, as to how using a string as a reference works ... I'm a little fuzzier on that. But, I do like using it, in very controlled doses. :)

Now, as to the second question ... I did a little further playing around and found that so long as the assignment of Apple never happened before the assignment of Red, for that given hash, neither hash correctly printed "Red Apple".

<speculation>
I'm going to guess that the moment the interpreter sees that the string 'Apple' can be made into a reference, it marks 'Apple' as a valid reference for everyone. Why it affects the hash seemingly defined before it? Because, the interpreter, in its first pass, will find all the possible references and remember those. Then, in the second pass, it will use those references it knows about.
</speculation>

Nifty theoretical problem!

I'm going to guess that the moment the interpreter sees that the string 'Apple' can be made into a reference, it marks 'Apple' as a valid reference for everyone. Why it affects the hash seemingly defined before it? Because, the interpreter, in its first pass, will find all the possible references and remember those. Then, in the second pass, it will use those references it knows about.

No, that's too much voodoo. It's simpler than that. The first hash assignment puts values in %main::Apple, using a symref (use strict would have caught that.) And the second set of assignments causes it to reference %main::Apple as well, the very same hash.

No magic needed to explain that.

-- Randal L. Schwartz, Perl hacker