Should I prefer hashes or hashrefs in Perl?

Question

I\'m still learning perl.

For me it feels more \"natural\" to references to hashes rather than directly access them, because it is easier to pass references to a sub, (

Answer 1

I think this kind of question is very legitimate: Programming languages such as Perl or C++ have come a long way and accumulated a lot of historical baggage, but people typically learn them from ahistorical, synchronous exposés. Hence they keep wondering why TIMTOWDI and WTF all these choices and what is better and what should be preferred?

So, before version 5, Perl didn't have references. It only had value types. References are an add-on to Perl 4, enabling lots more stuff to be written. Value types had to be retained, of course, to keep backward compatibility; and also, for simplicity's sake, because frequently you don't need the indirection that references are.

To answer your question:

Don't waste time thinking about the speed of Perl hash lists. They're fast. They're memory access. Accessing a database or the filesystem or the net, that is where your program will typically spend time.

In theory, a dereference operation should take a tiny bit of time, so tiny it shouldn't matter.

If you're curious, then benchmark. Don't draw too many conclusions from differences you might see. Things could look different on another release.

So there is no speed reason to favour references over value types or vice versa.

Is there any other reason? I'd say it's a question of style and taste. Personally, I prefer the syntax without -> accessors.

Answer 2

If you can use a plain hashes, to describe your data, you use a plain hash. However, when your data structure gets a bit more complex, you will need to use references.

Imagine a program where I'm storing information about inventory items, and how many I have in stock. A simple hash works quite well:

$item{XP232} = 324;
$item{BV348} = 145;
$item{ZZ310} = 485;

If all you're doing is creating quick programs that can read a file and store simple information for a report, there's no need to use references at all.

However, when things get more complex, you need references. For example, my program isn't just tracking my stock, I'm tracking all aspects of my inventory. Inventory items also have names, the company that creates them, etc. In this case, I'll want to have my hashes not pointing to a single data point (the number of items I have in stock), but a reference to a hash:

$item{XP232}->{DESCRIPTION}  = "Blue Widget";
$item{XP232}->{IN_STOCK}     = 324;
$item{XP232}->{MANUFACTURER} = "The Great American Widget Company";

$item{BV348}->{DESCRIPTION}   = "A Small Purple Whatzit";
$item{BV348}->{IN_STOCK}      = 145;
$item{BV348}->{MANUFACTURER}  = "Acme Whatzit Company";

You can do all sorts of wacky things to do something like this (like have separate hashes for each field or put all fields in a single value separated by colons), but it's simply easier to use references to store these more complex structures.

Answer 3

For me the main reason to use $hashrefs to %hashes is the ability to give them meaningful names (a related idea would be name the references to an anonymous hash) which can help you separate data structures from program logic and make things easier to read and maintain.

If you end up with multiple levels of references (refs to refs?!) you start to loose this clean and readable advantage, though. As well, for short programs or modules, or at earlier stages of development where you are retesting things as you go, directly accessing the %hash can make things easier for simple debugging (print statements and the like) and avoiding accidental "action at a distance" issues so you can focus on "iterating" through your design, using references where appropriate.

In general though I think this is a great question because TIMTOWDI and TIMTOCWDI where C = "correct". Thanks for asking it and thanks for the answers.