Archive for month: January, 2013

JavaScript Scope & Closures

January 25, 2013

One of the biggest challenges facing new JavaScript (JS) developers is the global nature of JS. Unlike other languages, almost everything in JS is global. Scope in computer programming, in simplest terms, is the extend of a properties visibility throughout the code. Many popular programming languages have block scope, meaning that you can enclose code within curly braces and hide it from other code. Take a look at the code block below:

Read more →

Introduction to JavaScript’s Prototype Inheritance

January 22, 2013

jslogoIf you have worked in traditional classical object oriented (OO) languages, JavaScript’s (JS) prototypal inheritance model may be a source of confusion. It certainly was for me when I started working in JS.

What is a “Classical Object Oriented model?”
Many people believe that the word “classical” in “classical OO” has something to do with tradition, or a history of OO programming. This is actually incorrect. The word classical in this instance actually refers to the base word “class,” which in OO means a data structure that allows one to create unique instances of objects through classes.  If you are familiar with Java or ActionScript3, you have most likely used classes.

How is “prototypal inheritance” different from “classical inheritance?”
Classes can inherit from other classes by extending them. When one class extends another, the extended class is often referred to as the base, super or parent class. For the purposes of this article, I will refer to them as a parent and child relationships when referring to inheritance. The child class inherits a specified set of methods and properties from the parent class.

Prototypal inheritance is based off an an actual instance of an object – not the construct to create that instance. So when you create your parent object with all its specific properties and methods, the child inheriting from the parent gets all the original objects values. They’re live and will change automatically for the child when its created.

I like to think of classical inheritance as blue-prints. You ‘construct’ things from blueprints, and each one will be unique and different. When a child gets a hold of the original parent’s blue-print, it can add on rooms and make changes, but it won’t affect any of the objects already created with either child blue-prints, or their parents.  It also does not require any parent objects to be created in order to create children.  They can be created directly from their own blueprints.

Read more →