Ruby Arrays and Hashes

Ruby and Object Collections

Data structures and the answer to the burning questions: "Where did I put that, and how do I get it back?"

Nov 10, 2015

What is an array, exactly?

Well, the dry, technical answer (from the Ruby language documentation) is that an array is an ordered, integer-indexed collection of any object. Less dryly, it's a list of, well, stuff. What stuff? Anything you like - numbers, strings, objects - heck, even other arrays - can be crammed into a cell of an array, and it'll just sit there, waiting for you to access it. Now, before we get too far into this, let's take a look at a representation of an array:

Value:	cat	dog	bird	pig	horse
Cell:	0	1	2	3	4

So... what is this? Well, it's an array with 5 cells, containing, in this case, the names of animals. Why animals? Honestly, they were the first thing I thought of. Note, specifically, how the cells are numbered. Computers languages are strange, and don't start counting at one - they start counting at zero!

So, then, what about hashes?

Again, the technical answer: A Hash is a dictionary-like collection of unique keys and their values. What's that mean? It's a way to connect values to symbols, and then allow access to those values through those symbols. Let's take a look at one again:

Value:	Morris	Rex	Tweety	Porky	Rex
Key:	:cat	:dog	:bird	:pig	:horse

Now, what's going on here? Basically, we've associated names with each of the animals, and we can look up each name by checking the type of animal. We did not need to use strings as the keys for the hash - any object can be used as a key value (just as any object can be used as the value value).

What's the difference?

Well, the main difference to notice between the storage methods is that the value in an array cell is always accessed by integers, while the value in a hash is accessed by referencing the key. Speaking in a very general sense, arrays can often be faster to use, as the data is stored in a much more ordered manner, while hashes are much more flexible. Obviously, there are also differences in the syntax used to initialize, access, and add values to the different methods. Both, however, share the iterator 'each' to allow you to access all the members in storage.

Okay, but why would you use one instead of the other?

Well, in a very basic sense, if you have a list of things that are not associated with another thing apart from the order you got them, an array is probably what you're looking for. If you're associating some pieces of information with other pieces of information, a hash is probably your best bet.

An example:
You, you lucky person, have been elected to go get lunch for everyone from the local sandwich shop. So, you go around the office, collecting everyone's order - Alec wants roast beef on rye, Beth wants turkey and cheddar, and so on. In a sense, what you're doing here is creating a hash - you're associating the sandwich order (your value) with the name of the person who ordered it (your key), so that you can distribute the food accurately when you get back. Make sense?
Now, you're at the shop, placing the order (iterating over the hash, returning the values sans keys). The sandwich maker cares not for the names of the people who want the sandwiches, just what sandwiches need to be made. So, the order is sent back: roast beef on rye into cell 0, turkey and cheddar into cell 1...the sandwich maker is making an array (and sandwiches, one would hope) - the only important information is the sandwich order, unassociated with anything else. So, then, the sandwich maker iterates over that array, making the sandwich contained in each cell, and sending you back to work with everyone's order. Which you then distribute by iterating over your hash one more time, matching the sandwiches to the people who ordered them.

And so, there's a quick overview of arrays and hashes. Here's a short list of resources that are helpful on this subject.

Paul Dynowski

Fledgeling Web Developer, All-Around Swell Guy