See References Quick Reference.

The arrow operator dereferences a reference. As the documentation says, in a multi-level data structure, you can omit the arrow between certain levels.

You do need something to disambiguate between @array and $array, where the latter contains a list reference. That's why you can use either $array->[0] or $$array[0] to access the first element. Still, see the link above.

$$player_dbref{player_name}{ip_addr} = "1.2.3.4";
$$player_dbref{player_name}{id}      = 007;
[download]

I think you have your arrays and hashes a bit mixed up.

So usually I'd use $$player_dbref{happyplayer}{22.22.22.22} to get the user id and to get that I'd have to traverse the hash keys to find the name of a player and then I'd have to traverse the hash again with the player's name I just got as the key to get the IP and so on and so forth.

Actually, I don't think it works like that: happyplayer is the name of a player already: you don't have to traverse the hash to find it, you just key into it directly and its value is a reference to another hash, which is keyed by IP.
The same goes for $$player_dbref{player_name}{ip_addr}{id}. id is already the id as key to whatever value you like to put in that slot.

The way you have set-up this hash is such that every player can have many IP's, which each can have many ID's, which finally point to 'a value' (I can't find in your post what this value seems to be)). But you never actually store --as values that is-- names of players, their IP's or their ID's. All these data are only existing as keys into the hashes which yield you references to other hashes and finally to a value, which is not used AFAIK.

ALso, note that every "player" has its own hash of IP-references and each IP has its own hash of ID-references. There is actually no connection between the IP's for the different players: i.e. you cannot "easily" traverse all IP-references for all players: these references are not in the same hash! The same goes for your ID-references.

I would suggest you play around a bit with Data::Dumper to see what I mean and to see what and how things are stored in your HoH.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

So usually I'd use $$player_dbref{happyplayer}{22.22.22.22} to get the user id and to get that I'd have to traverse the hash keys to find the name of a player and then I'd have to traverse the hash again with the player's name I just got as the key to get the IP and so on and so forth.

Actually, I don't think it works like that: happyplayer is the name of a player already: you don't have to traverse the hash to find it, you just key into it directly and its value is a reference to another hash, which is keyed by IP. The same goes for $$player_dbref{player_name}{ip_addr}{id}. id is already the id as key to whatever value you like to put in that slot.

You might have misunderstood what I was saying. My code works. In fact, I use Data::Dumper all throughout my code to watch my hash grow and shrink. What I was saying was (which works but I don't think its the best way to do it from an ease-of-code point of view) is I am using a hash reference with rvalues of the data as the keys to the hash. Thus a key to %$player_dbref would actually be referenced as $$player_dbref{$player_name}{$ip}{$id} since I don't know what the keys in the reference are yet. Therefore, I have to traverse the hash table to get the values (first the player name, then the ip, and then the id) in the HoH.

Actually, I was able to make a change based from Paladin's comments. May I just say right now...DUH to me in reference to the idea of using $$player_dbref{$player_name}{id} and $player_dbref{$player_name}{ip} for my hash table! Why didn't I think of that?!?! =P (/me humbly kicks himself). I already sent a message to Paladin for his remarks but thank you again Paladin! So I have changed my code as thus and it works *much* better (much easier to add or subtract keys from the hash) and is way more portable. See? I was making it harder than it needed to be.

Also, I now fully understand the arrow operator! Thanks again fellow monks!

As a sidenote I realized something. A hash of hashes need only be as difficult as related to what needs to be unique in the table. In other words, in my code, the unique key was the player name only because that will always be unique in the game (the IP won't always be because of multiple clients running on the client machine and the id would be but I haven't made a clear decision to key off that value yet). Thus, for tracking a player if I don't know what a player's name is I need only traverse the hash for a particular player's name and from there I now have everything I need for that player; the id, the ip, eventually the map, and anything else I need to know about that player.

_ _ _ _ _ _ _ _ _ _
- Jim
Insert clever comment here...

use Data::Dumper;

use strict;

my %a = (1,2,3,4);
my $a_ref = \%a;

print "not ref, without ->\n";
print $a{1}, "\n";#good
print $a{3}, "\n";#good
print "not ref, with ->\n";
print $a->{1}, "\n";#uninitialized
print $a->{3}, "\n";#uninitialized
print "ref, without ->\n";
#print $a_ref{1}, "\n"; #cannot uncomment
#print $a_ref{3}, "\n"; #cannot uncomment
print "ref, with ->\n";
print $a_ref->{1}, "\n";#good
print $a_ref->{3}, "\n";#good
[download]

One thing I find helpful when dealing with complex data structures is to break it down one layer at a time, and get a clear understanding of what each element of each structure actually looks like. You can pretend, for the purposes of this exercise, to be doing OO-Perl, and give a name to the "class" of each element, which can help you draw pictures or write explanations.

So, for your code (assuming I'm understanding it properly):

1. %$player_dbref is a map from player names to let's call them Player objects. So
   $player = $player_dbref->{$a_name};

   To answer your original question, this is the only place where the arrow operator is necessary. But because this is Perl, and TMTOWTDI, you can (and have been) replacing $hr->{k} with $$hr{k}, which is the same thing.

2. Now from your example, it looks like a Player (a person with a particular name) can log in from multiple places, each resulting in in what I'll call a PlayerInstance. Thus:
   $player_inst = $player->{$an_ip};

   Combining this with the previous item yields
   $player_inst = $player_dbref->{$a_name}->{$an_ip}
   or
   $player_inst = $player_dbref->{$a_name}{$an_ip}
   since you can eliminate the arrow after the first dereference.

3. Finally, a PlayerInstance is what? Well, in your example you don't show anything other than an id, so if you really don't have any other data to store, you don't even need another bunch of references, but have $player_inst above be the (numeric) userid value.

   However, I'm going to assume you have other information to store, and then there are two possibilities:

   1. There is only one possible id for each name/ip combination, in which case a player instance is just a (reference to a ) hash from data keys to values, for example:
      

                     $id        = $player_inst->{id};
                     $hitpoints = $player_inst->{hp};
                     $weapon    = $player_inst->{weapon};
      [download]

      Let's call one of these things a PlayerData

   2. The other possibility is that you have multiple possible IDs per name/ip combination. This seems likely, given your example. In that case, a player instance is a map from IDs to PlayerData things. Then:
      

                    $playerdata = $player_inst->{$an_id};
                    $hitpoints  = $playerdata->{hp};
      [download]

      <it>etc</it>.

   Now, you can combine this with the previous items, and get:
   $hitpoints =  $player_dbref->{$a_name}{$an_ip}{$an_id}{hp}

But the nice thing is that all those intermediate steps are legal, and there's no reason not to do them if you have a need to. So:

To find all the IPs for a particular player

keys %$player, or keys %{$player_dbref->{$a_name}}

To find all the IDs for a player at a particular IP (assuming there's more than one)

keys %$player_inst, or
keys %{ $player->{$an_ip} }, or
keys %{ $player_dbref->{$a_name}{$an_ip} }

HTH!

--roundboy