"fallenrogue" Under Leon's hat.

JavaScript Part 2 - The Free Stuff

This is a tough one. I don’t generally like to discuss the built in objects of a language because they are easily searched for. Instead I’ll list a few and then talk about using them as that’s a little more subjective and worthy of discussion and continual review.

Quick Reference:

Types

• Numbers
• Strings
• Booleans (true|false)
• Objects
• undefined and null

Special Objects

• Date
• Regular Expression
• Functions
• Array

So, yeah, mostly these will function as you’d expect them to. Therefore, as I stated before, let’s skip that. Instead let’s discuss some fun things that are legitimately ambiguous to developers sharpening their JavaScript knives.

Objects in JavaScript

One of the things that throws folks is the notion of object being a specific type and staying that way after being initialized from a class. But in JavaScript objects are more like Hashes in Ruby or Dictionary<key, value> in C#. If you make that mental connection then seeing the JavaScript Object Notation (or JSON) will provide context for what you’re working with.

If you remember from part one, our first object creation was done as such:

If you look the object is created as it’s defined using the object notation which looks remarkably familiar to just some key-value collections mentioned about. When doing this you can then access those properties on the person instance using the dot or [] notation

person.name
person["name"]

both are fine ways to access the properties on your objects. So, knowing that, there are a couple of ways to create new objects in JavaScript they both establish a direct relationship to the super “Object” class.

var person = new Object();
var person = {}; 

{} is object notation so by specifying it on the right side of the assignment operator (=) yields a new Object instance to person.

There are many different ways to use the properties of this new object (which we mentioned earlier see new/[]) but the important thing to note is that since our objects have no concrete relationship to strong types we can access and assign properties on our objects at will.

person.likes_cake = true

if perfectly legal even if the member “likes_cake” is not a property on person. This allows for some real dynamic behaviors to occur at runtime. So, why would you use [] vs the . property syntax? Well, if you’re a daring individual you could assign properties that are named the same as reserved keywords. for example, “if” is a reserved keyword in JavaScript so just coming out with

var letter = {};
letter.for = "leon@foo.com"

is not going to work. BUT if use the [] property notation we can!

var letter = {};
var letter["for"] = "Leon@foo.com"

pretty cool stuff there! I don’t know that you’d want to do it from an idiomatic standpoint but it’s possible if you’d like to have it.

Functions

Functions are important to understand and as a bonus they are remarkably simple to understand. Basically, here are the “rules” to live by…

• defined with the function keyword
• optional name
• optional argument list
• code block to be executed when the function is executed.

AND as a bonus every function gets a few properties that may be of value. One of my favorites is the “arguments” object. It’s just an array of all the arguments that were passed to the function. Let’s play a bit with it.

pretty excellent stuff, right? many languages share this feature but I enjoy the compact way that JavaScript lets you extend the use of a functional all the way to runtime. Now that’s fun but with all languages that provide higher order functions it becomes very important to understand how they can be called recursively. Tail recursion (in short: last part of the function calls itself again until told not to) is an important concept but how do you know what do call again if your function has no name? Well, the answer lies in the arguments object. Let’s write a small tail recursive anonymous function. We’ll assign it so that we can call it a first time but since it doesn’t know what it’s own name we’ll use the arguments object’s callee property to call the method until we’re done. Type along with me using FireBug…

In there we see 2 things: first that the callee property is a little more than just a pointer to the current function, it also is an object that is persisted across the function calls so we were able to use that to hold a reference to a number as we counted down from the first argument that was passed in. Pretty cool, right!? That’s some wonderful, powerful introspection and provides JavaScript some of that signature magic that makes me fall in love with it over and over again.

Next we’ll take a look at arguably the most powerful feature in JavaScript and one that has gained a lot of exposure in other languages recently: closures.

Closures

Now closures have variation of definition and the minutiae of that semantic debate are not in the scope of this article. Instead let’s go with the following simplistic definition: closures maintain the scope of the variable at the time that the function is created and persisted after you believe they have fallen from scope. A simple example of this “scoping” would be using an inner function to establish an outer scope while establishing an inner scope for later use.

function greeting(prefix){
    return function(name){
     return prefix + " " + name;
 };
}

helloTo = greeting("hello there,")
document.write(helloTo.toString());
document.write("<br><br>");
document.write(helloTo("Leon"));

let’s run this code to examine the results in our REPL environment: FireFox+FireBug :)

That’s enough for now, friends!