"...and he was never heard from again!" Things in the brain of one T.Armstrong

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 28.0px; font: 22.0px Arial; color: #444444} p.p2 {margin: 0.0px 0.0px 10.0px 0.0px; line-height: 19.0px; font: 14.0px Arial; color: #444444} p.p3 {margin: 0.0px 0.0px 10.0px 0.0px; line-height: 19.0px; font: 14.0px ‘Lucida Grande’; color: #444444} p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 19.0px; font: 14.0px Arial; color: #444444} p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 19.0px; font: 14.0px Arial; color: #444444; min-height: 16.0px} span.s1 {font: 14.0px ‘Lucida Grande’} span.s2 {font: 14.0px Palatino; color: #181818}

Another week, another couple of Chapters of Eloquent JavaScript. Here is my take on the subject matter for Week 2. I have been behind on these, for which I humbly beg your forgiveness. I have a stack of almost-finished drafts piling up in tumblr… and I will now attempt to push them out the door in their varying states of half-baked-ness.

Week Two focussed on a couple of “data structures”, which are simpler than they sound - just different ways to store things that you’re working with in the programs you write.

In my last post I described “variables”: a way keep track of important bits of data in your program by “pinning” labels to them, as though you were sticking them to a cork board with a labelled push-pin. This is one way of keeping track of information in a program, but what if you need to store or organise a whole stack of bits of information together, and sort through them?

Just like a cork board and push pins, variables are useful, but they get impractical when you need to store and track a lot of related pieces of data. That’s what “objects” and “arrays” are for.

“Objects” can be thought of like filing cabinets (yeah, not the most original metaphor, I know - gimme a break!), in which you can put a whole collection of pieces of information and values (In programming-speak, they’re called “properties”.) Like files in a cabinet, every item in there (ie. every “property”) has a label on it. This let’s you retrieve things by their label, or name. The computer is like an efficient but dimwitted assistant - you can ask it for a particular item, but only by label/name - your assistant doesn’t have the initiative to go looking for the file you *might* have meant. This filing cabinet isn’t kept in any particular order, either. Blame that assistant of yours. 

You can put a lot of different things in this filing cabinet (aka. Object), but you can only retrieve them if you know the name, and it’s not particularly easy to sort through them all in an orderly way. However, objects have an ace-in-the-hole: you can even put functions into them. You might imagine this like writing down a set of instructions or plans, and then storing them away in a particular filing cabinet. When the time is right, you can access this “method” by name. Just imagine calling out to your dimwitted assistant: “Charles: run contingency plan ‘alphaThree’!” At which point he leaps into action, burns the office to the ground, and slips a cyanide pill under his tongue to avoid capture ;) 

In general, writing “objects” and “methods” like this is a way to keep the structure of your program (or your “office” if you’re really in love with that metaphor) clean, easily understandable, and flexible. So if you need to move a desk or chair around, it doesn’t throw the whole office into chaos.

“Arrays” are a bit different. They’re more like ring-binders full of loose-leaf paper. They’re organised differently to “objects”/file cabinets: the pages or bits of data inside them don’t have labels or names to refer to them, -however- in this particular binder, the pages are numbered. This means that you *can* refer to them by number, or get your dim-witted assistant (remember him?) to leaf through them in order. You can also stick a new page in at the front - a move called a “push”, or “pop” the last page off. You can get your assistant to grab a “slice” of pages from somewhere in the binder, if you tell him the “index” or page numbers of the bit that you want. Being dimwitted but efficient, your assistant keeps the binder up to date, updates the “index”/page numbers etc. He’s kind of OCD like that - just a shame he’s so thick when it comes to other stuff :P

Here endeth the metaphor: that’s basically the difference between objects and arrays in a nutshell. Objects are more flexible, can contain a wider variety of values, even functions, and have labels or “keys” so you can access their values by name. In contrast, arrays have only numerical indices to refer to their contents. This makes them more suitable for some things, however: allows you to easily loop through their contents in order, access the item at a given index or position in the order, and reorder them as you see fit.

Chapter 5 of Eloquent JavaScript concerns handling errors. According to EJ, these tend to fall into two different categories : programmer errors, and errors caused by incorrect or unexpected input. Programming errors should be dealt with by finding and fixing them - but the other kind of errors can be more challenging to deal with. In general, it is a bad thing for a function in your program to fail “silently”, ie. without any indication that it has failed and is providing wrong or nonsensical output to the rest of the program. Coping with this prospect involves thinking about what kind of input that function expects to receive, and what could cause it to go awry, and planning for this in order to salvage the error, or at least fail gracefully and let the user know that something is wrong. A powerful tool for solving these kinds of errors is the “exception”. You can think of this as a part of the program taking “exception” to unruly behaviour from a particular piece of input, or imagine functions in your program as rule-bound workers who have the flexibility to realise (because you’ve told them how!) that something has gone wrong and requires an “exception” to their normal procedures. Either way, once an exception has been “thrown”, it is fielded or “caught” by another part of the program designed to cope with errors. If you don’t write a function to catch exceptions yourself, they’ll be caught by the environment.

Some nice gibberish for the course aggregator: /*#p2pu-Jan2011-javascript101*/