Re: Lamens terms how-to on HoH refs and the arrow operator

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

Comment on Re: Lamens terms how-to on HoH refs and the arrow operator

Replies are listed 'Best First'.

Re: Re: Lamens terms how-to on HoH refs and the arrow operator
by snafu (Chaplain) on Dec 27, 2002 at 18:27 UTC

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...

[reply]
[d/l]
[select]