Re^3: when is "my" not necessary?

Well...

my $hash;
$hash{foo} = bar;
[download]

Creates a lexical scalar named $hash

Assigns 'bar' to the key 'foo' in the global variable %hash (or, more accurately, %main::hash)

If you meant:

my %hash;
$hash{foo} = 'bar';

#Versus

my $hash = {};
$hash->{foo} = 'bar';
[download]

Then there is still a difference. In the first, you create a lexical hash named %hash, then assign a value to one of it's keys. In the second you create a lexical scalar which contains an anonymous reference to a hash.

To examine the difference, run this:

#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper;

print "A lexical hash:\n";
my %hash;
$hash{foo} = 'bar';
print Dumper(\%hash);

print "A lexical hash *reference*:\n";
my $hash = {};
$hash->{foo} = 'bar';
print Dumper(\$hash);
[download]

Note how the variable in the second case "points to" (is a reference to) the actual hash, while the first case is just the hash. I highly suggest reading up on references, and man perlvar -- the nuances are important and often incredibly useful. ;-)

radiantmatrix
require General::Disclaimer;
"Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy

Comment on Re^3: when is "my" not necessary? Select or Download Code

Replies are listed 'Best First'.
Re^4: when is "my" not necessary? by argv (Pilgrim) on Nov 06, 2004 at 06:22 UTC
Folks, as lovely and complete as your responses were, they were merely explanations for the differences between `%hash{}` and `$hash->{}`. My question, however, was what is the advantage of using one over the other? Obviously, there are contextual sitautions where you are supposed to use one instead of the other, but in cases where you are just creating a dynamically growing hash, does it matter which? If the question is still too simple to answer one way or another, how about answering this: under what conditions is one more efficient memory-wise, performance-wise, or otherwise? Independently of that question, let me throw in this: I have a text file that I parse with perl and build hashes based on that data. Think of it as a cross-referencing dataset with references pointing every which way. In order to avoid reparsing this each and every time the program starts up (it'll be a cgi script, and the data it reads is static), what would be the best way to just dump the hashes into a file and load it back up in one swell foop so as to optimize performance? Would the above "Dumper" package be a good choice? And in this case, would I want to use the hash reference form discussed above? dan	[reply] [d/l] [select]
Re^5: when is "my" not necessary? by runrig (Abbot) on Nov 17, 2004 at 00:37 UTC
what is the advantage of using one over the other? The syntax when dealing with hashes is simpler than when dealing with hash references. When I want to pass them around as arguments though, I tend to use hash references instead. And if you want a hash to be part of a larger data structure, you have no choice but to use references (unless you use a glob, but let's not go there). what would be the best way to just dump the hashes into a file and load it back up in one swell foop so as to optimize performance? Would the above "Dumper" package be a good choice? And in this case, would I want to use the hash reference form discussed above? Data::Dumper is good for "seeing" the contents of a data structure for debugging purposes, but for storing and retrieving data, Storable deals better with things like odd characters such as line feeds in the data, though the file it creates is not readable like the output of Data::Dumper. You can also look at things like DBM::Deep (update: or YAML or XML (e.g. XML::Simple) modules).	[reply]
Re^6: when is "my" not necessary? by demerphq (Chancellor) on Nov 17, 2004 at 21:54 UTC
I hope I'm not out of line in adding Data::Dump::Streamer to the list. It not as fast as storable or Data::Dumper but its a lot easier to read and handles a lot of the weirder cases better and more accurately than DD. --- demerphq	[reply]