The Null and Undefined types are the only existence types in JavaScript. These types and their values are special because they don't represent data, but instead stand for the absence of data.

The Null type has only one value, which is represented by the null keyword. The null value denotes the absence of a value: assigning null to a variable means that the variable does not have an actual value. Thus, the Null value is like a placeholder value in cases where there's no value to use.

Like the Null type, the Undefined type has only one value, which is represented by the undefined variable. The undefined value is used to represent the value of any variable that has been declared but not defined:

// declare a variable
var thing;

console.log(typeof thing); // 'undefined'
console.log(thing === undefined); // true

// define the value
thing = 1;

console.log(typeof thing); // 'number'
console.log(thing === undefined); // false

Remember that in Chapter 2 we learned that variable declaration and variable definition are executed by JavaScript as two distinct steps. When a variable is declared but not given a value, its value is automatically set to undefined. The undefined value is also used as the value of object members that don't exist, as well as the value of a function's formal parameters with no corresponding argument passed during invocation.

One important thing to consider with the Undefined type is that its only representation—the undefined variable—is a variable, not a keyword. This means that the actual value of the undefined variable can be changed:

// declare a variable
var thing;

// change the value of undefined
undefined = 'nooo!';

console.log(thing === undefined); // false

The ECMAScript committee's decision to make undefined a variable was an unfortunate choice that's been resolved in ECMAScript 5 by making the variable read-only. However, you should still be careful not to change the value of the undefined variable since ECMAScript 3 is still widely used, and doing so would create havoc in your programs.

The null and undefined values can be transformed into primitives through type casting—and we'll see how this is done in a later section. For now, let's just remember that the null value is cast into the number value 0, the string value 'null' and the boolean value false. Meanwhile, the undefined value is cast into the number value NaN, the string value 'undefined' and the boolean value false.

Null and Undefined also have the distinction of being the only native types with no constructor functions. Therefore, they have no corresponding MooTools type object. Any variable that has null or undefined for its value will have no properties or methods, and trying to access a member of a null or undefined value will result in an error.

One important thing to note here is that MooTools treats the Undefined value the same as the Null value, which means that typeOf(undefined) will return 'null' instead of 'undefined'. This is a simplification on the part of MooTools, since both values represent the same state of not having an actual value. Therefore, in order to check for undefined in MooTools, you'll have to use strict comparison, such as value === undefined.

The three primitive types—Number, String, and Boolean—represent the simplest of all possible values in JavaScript. They're the most basic types of data in terms of structure, containing only actual values without any properties or methods.

Primitive values are immutable, which means that they can't be modified. When a primitive value is stored in a variable or passed as an argument to a function, a new copy of the value is created—giving them their other name, value types.

console.log('Hello World!'.substring(0, 4)); // 'Hello'

console.log( typeOf('M!'.hasOwnProperty) ); // 'function'
console.log( typeOf((42).hasOwnProperty) ); // 'function'
console.log( typeOf(true.hasOwnProperty) ); // 'function'

console.log( typeof 'hello' ); // 'string'
console.log( typeof new String('hello') ); // 'object'

console.log( typeof 42 ); // 'number'
console.log( typeof new Number(42) ); // 'object'

console.log( typeof false ); // 'boolean'
console.log( typeof new Boolean(false) ); // 'object'

console.log(new String('Hello World').substring(0, 4)); // 'Hello'

var str = 'Hello World';
str.type = 'greeting';

console.log(str.type); // undefined

var str = new String('Hello World'),
str.type = 'greeting';

console.log(str.type); // 'greeting'

JavaScript has only one composite type: the Object type. However, it can be divided into subtypes that define the special kinds of objects, such as arrays or dates. Unlike the native type system, the MooTools type system differentiates between objects according to these subtypes.

We already talked about objects in detail before, so we won't go into the internals of JavaScript's object implementation here. We know that objects are aggregate values composed of an unordered collection of key-value pairs. We also know that all objects are associated with a constructor function and they inherit from the prototype property of their respective constructor.

Unlike primitives, objects are mutable: their structure and their behavior can be changed. When stored in variables or passed as arguments, new copies of the object aren't created. Instead, a reference to the original object is passed, effectively "sharing" the same object in all operations. Because of this behavior, objects are also called reference types.

The ECMAScript specification divides objects into two kinds:

We have already seen some of these native and host objects, like functions, objects, and classes, in the previous chapters. We'll discuss most of the browser-specific host objects in the second part of this book, and the CommonJS host objects in part three.

// a basic object
var obj = new Object();

console.log(typeOf(obj.constructor));    // 'function'
console.log(typeOf(obj.hasOwnProperty)); // 'function'

for (var key in obj) console.log(key);

[1, 2, 3].join(','), // '1,2,3'

{
    '0': 1,
    '1': 2,
    '2': 3,
    length: 3
}

// real array
var arr = [1, 2, 3];

for (var i = 0, l = arr.length; i < l; i++){
    console.log(arr[i]);
}

/* output:
    1
    2
    3
*/

// "object" array
var objArr = {
    '0': 1,
    '1': 2,
    '2': 3,
    length: 3
};

for (var i = 0, l = objArr.length; i < l; i++){
    console.log(objArr[i]);
}

/* output:
    1
    2
    3
*/

var objArr = {
    '0': 1,
    '1': 2,
    '2': 3,
    length: 3
};

console.log(typeOf(objArr)); // 'object'

// turn it into a true array
objArr = Array.prototype.slice.call(objArr);

console.log(typeOf(objArr)); // 'array'

var objArr = {
    '0': 1,
    '1': 2,
    '2': 3,
    length: 3
};

console.log(objArr.length); // 3

// the first member of the array
console.log(objArr[0]); // 1

// add a member to the front
Array.prototype.unshift.call(objArr, 0);

console.log(objArr[0]); // 0
console.log(objArr.length); // 4

// add a member to the back

Array.prototype.push.call(objArr, 4);

console.log(objArr[4]); // 4
console.log(objArr.length); // 5

// check that it's still an object
console.log(typeOf(objArr)); // 'object'

The first and easiest way to explicitly cast a value to another type is to use the built-in constructors. Most native JavaScript constructors can actually be invoked as regular functions, and they perform type conversions when used this way.

The constructor objects for primitive wrappers, for instance, can be used to convert values to primitive types:

// boolean
console.log(Boolean(0));        // false
console.log(Boolean(''));       // false
console.log(Boolean('24'));     // true
console.log(Boolean({}));       // true

// number
console.log(Number(false));     // 0
console.log(Number(''));        // 0
console.log(Number('24'));      // 24
console.log(Number({}));        // NaN

// string
console.log(String(false));     // 'false'
console.log(String(24));        // '24'
console.log(String({}));        // '[object Object]'
console.log(String([1, 2, 3])); // '1,2,3'

The casting operations here follow the same rules we described earlier: primitives are converted using the rules for converting one primitive type to another, while objects are converted using their valueOf and toString methods.

An important thing to remember is that the return values of these primitive conversions are actual primitive values and not objects—only when used in conjunction with the new operator do they return objects. Thus, String(1) will return the primitive string value '1', while new String(1) will return a new string object.

Native object constructors, on the other hand, behave differently when used as regular functions. The Function, Array, RegExp, and Error constructors, when invoked as regular functions, operate the same as if they were used with the new keyword. Thus, they don't actually perform type casting, but rather, they perform object instantiation. It is therefore advisable not to invoke them as regular functions.

The Date constructor's behavior, in contrast, is unique when it's invoked as a function: it doesn't perform type casting nor does it create a new date object. Instead, it returns the current date as a string.

Finally, the Object constructor performs type casting according to the actual type of value passed. If you pass in a primitive value, it will return a wrapped object version of that value—so you'll receive either an instance of String, Number, or Boolean. But if you pass in an object value, the constructor will simply return the same object, with no modification. And if you pass in null or undefined, it will return a new plain object—just like doing new Object().

There are two special functions defined in JavaScript that handle string-to-number conversions: parseFloat and parseInt. Unlike the Number constructor, these functions are more lenient when used for parsing strings, as they allow non-numeric trailing characters in the strings.

The parseFloat function converts both integer and floating point numbers, while parseInt can only convert to integers:

console.log(Number('42 is the answer.'));       // NaN
console.log(parseInt('42 is the answer.'));     // 42
console.log(parseFloat('42 is the answer.'));   // 42

console.log(parseInt('3.14'));      // 3
console.log(parseFloat('3.14'));    // 3.14

console.log(parseInt('024'));       // 20
console.log(parseInt('024', 10));   // 24

The last two lines feature a quirk with the parseInt implementation. The parseInt function has a special "feature" that treats strings that begin with 0 as octal values. Thus, parseInt('024') returns the value 20 instead of 24. This creates a problem when parsing non-octal strings that start with 0, although you can solve it by passing a second argument, radix, which tells the function what base to use for the conversion. This "feature" has been removed in ECMAScript 5.

One idiom that's used to convert any value to a number is JavaScript's implicit type conversion for mathematical operations. By using numeric identity operations (such as subtracting 0 from a value or dividing or multiplying a value by 1), you can convert a value to a number:

console.log('42' / 1); // 42
console.log('42' - 0); // 42
console.log('42' * 1); // 42

console.log(true - 0); // 1
console.log(false * 1); // 0

console.log({} - 0); // NaN

But don't use the addition identity operation (x + 0) because the + operator is both the addition and concatenation operator in JavaScript. You can, however, use + as a unary operator for the purpose of numeric casting:

console.log(+'42'), // 42
console.log(+true); // 1
console.log(+{}); // NaN

To convert any value (except for null and undefined) to a string, we can simply use the toString method. This works with primitives as well because of the automatic object wrapping mechanisms:

console.log(true.toString());       // 'true'
console.log((42).toString());       // '42'
console.log([1,2,3].toString());    // '1,2,3'

Another way to convert values to strings is to exploit the concatenation operator, +. This operator is used for both addition of numbers and concatenation of strings, but it gives special priority to string values: if one of the operands in the expression is a string, it also casts the other value into a string. We can therefore turn any value into a string by concatenating it with an empty string:

console.log(true + ''),     // 'true'
console.log(42 + ''),       // '42'
console.log([1,2,3] + ''),  // '1,2,3'

Finally, casting values to booleans is rarely done since JavaScript allows any value to be used in place of an actual boolean value when needed. If you do want to convert a particular value into its boolean representation quickly, though, you can use the double-negation trick:

console.log(!!''), // false
console.log(!!'M'), // true

console.log(!!0); // false
console.log(!!42); // true

console.log(!!{}); // true
console.log(!![]); // true

The negation operator, !, automatically casts a value into a boolean and it reverses a boolean true value to false and vice versa. Using the negation operator twice yields the same boolean value that was negated at the start of the expression. For example, the number value 0 is cast to the boolean value false. When negating this value, we get !false == true. The true value is then negated again, and the final value goes back to false. Thus, we get a proper conversion from 0 to false.

The Type constructor accepts two arguments: a required name argument, which should be a string representation of the capitalized type name, and an optional object argument, which is the constructor function to be transformed. If an object argument is passed, the Type constructor returns the same object after it adds additional properties and methods to it. Otherwise, it returns null.

As I mentioned earlier, the Type constructor doesn't create new constructor functions but rather transforms already existing constructors into type objects by augmenting new properties and methods to it. To illustrate, here's how the native Array constructor is turned into a type object:

new Type('Array', Array);

And that's all it takes to turn a native constructor into a type object. We simply instantiated a Type object using the new keyword and passed the name of the type, 'Array', and the native Array constructor function. You'll notice that we didn't even need to store the results in a variable. Because the Array constructor is transformed directly, there was no need to store the result of the expression in a new identifier. The process is both simple and elegant—and certainly says a lot about the MooTools type system implementation

One question that continually pops up when developers see that example is whether the new keyword is actually needed. If we're not really creating a new object but simply transforming an existing constructor function into a type object, why not just make Type a simple function? Does it really have to be a constructor?

The question is even more valid once you consider the fact that instances of Type are not really "instances" of Type:

new Type('Array', Array);

// make sure that Array is a type object
console.log(typeOf(Array)); // 'type'

// is Array an instance of Type?
console.log(Array instanceof Type); // false

We do know that Type transforms the constructor directly, so it really doesn't create a new object. The type object returned by the Type constructor isn't really an instance of Type since it's a function that already existed before we passed it to the constructor. So does this mean we could really do away with using new?

To answer this question, we must first examine the same question but with regard to classes, which are similar to type objects. Unlike the Type constructor, the Class constructor actually creates a new constructor function for the class, so using the new operator with Class seems like a logical thing to do. What's surprising is that the same behavior can be observed in classes as well:

var Person = new Class();

// make sure that Person is a class

console.log(typeOf(Person)); // 'class'

// is Person an instance of Class?
console.log(Person instanceof Class); // false

This seems a little counter-intuitive: the Class constructor creates the new constructor for the class, so we'd expect that the result of instantiating the Class constructor would be a class instance. But when the instanceof operator is used to check, classes exhibit the same behavior of not being instances of the Class constructor—just like type objects with Type.

Recall something I mentioned earlier in this chapter about functions: they are one of the two types of objects in JavaScript that can't be created using a basic object (the other being regular expressions)—which means they can't be subclassed. The reason for this is simple: functions depend on an internal call property that references the executable code that's called when the function is used in conjunction with the invocation operator. Since we have no way of setting this internal property in regular objects, we can't create subclasses of the Function type because we'll end up referencing the same executable code.

The Type and Class constructors both deal with constructor-prototype pairs, with emphasis on constructors. In essence, type objects and classes are "subclassed" functions: they're constructor functions that have special properties and methods. But because JavaScript places no distinction between regular functions and constructors (except for their behavior when used with new), both Type and Class need to circumvent the limitation of function subclassing using direct augmentation of functions, rather than simple prototypal inheritance.

Here's how it works. For the type definition new Type('Array', Array), a new object inheriting from Type.prototype is created by the new operator and then used as the this value inside the Type constructor. Type then takes all the properties and methods of this new instance and adds them to the Array constructor function, thereby making sure that the resulting Array type object will "inherit" the members in Type.prototype. The operation involves direct augmentation of members to the type object, and not inheritance via the prototype chain. The new keyword is essential because it creates the template object that will be used for augmentation. The same thing is applicable to the Class constructor, with the minor difference of the resulting class object being created inside the Class constructor itself.

Of course, direct augmentation has its limitations, which we already saw in the Chapter 3. The main issue would be dynamic modification: since type objects and classes are augmented directly, any changes to Type.prototype and Class.prototype aren't propagated to existing type objects and classes. This isn't a big issue in practice, though, since the number of type objects and predefined classes in the MooTools-Core library are small enough to modify directly.

The snippets above don't just show why we need something like the new operator when we're creating new type objects, they also shows us some limitations encountered when trying to implement a new type system on top of the existing one. In order for the replacement MooTools type system to be fully usable, it needs to cover not only the creation and management of types but also things like instance checking and type detection.

Interestingly, the core mechanisms for adding these two features to the MooTools type system are implemented by the Type constructor itself, as we'll see in the next two sections.

Native JavaScript instance checking is done using the instanceof operator. We've already seen it in action several times in this and earlier chapters, so it hardly needs any introduction.

The instanceof operator works by comparing the constructor of the object on the left-hand side of the expression to the constructor function on the right-hand side. In the expression myCar instanceof Car, for example, the constructor function that created the myCar object is compared to the Car constructor to see if they're the same function. If they are, the expression evaluates to true.

However, if the constructor function for the myCar object and the Car constructor aren't the same, the expression doesn't immediately evaluate to false. Instead, the prototype chain of the myCar object is traversed, and the constructor function of each object in the prototype chain is compared with the Car constructor. Only when the last constructor function has failed comparison will the expression evaluate to false.

This "deep" comparison is why the instanceof operator evaluates to true not only for the immediate constructor of the object, but also the ancestral constructors of the object. All objects are therefore seen as instances of the Object constructor, since all objects inherit from Object at one point in their prototype chain.

As you've probably guessed by now, the constructor property of objects plays a central part in native instance checking. All objects are linked to their corresponding constructor functions via their constructor property, and it's the value of this property that gets compared to the constructor function on the right-hand side of the expression.

In our examples in the previous section, both type objects and classes fail the instanceof test because they don't have links to the Type and Class constructors directly. Both type objects and classes are abstracted constructor functions, so their prototype chain consists only of instances of Object and Function. Because the Type and Class constructors augment these constructor functions directly rather than through prototypal inheritance, their constructor functions never get "linked" to the object. Thus, type objects and classes are not seen as true instances of their respective constructors by the instanceof operator.

To circumvent this limitation, a link has to be made by the MooTools type system between these objects and their constructors. This is done by adding a new property to these objects called $constructor. Like its native constructor counterpart, the $constructor property is a reference to the object's original constructor function. Type objects therefore have their $constructor properties pointing to Type, while classes have theirs pointing to Class.

Of course, just because MooTools added a new property that resembles the native constructor property doesn't mean that instanceof will respect it. The MooTools type system works on a separate level from the native one, so we can't expect a simple solution like that to take care of the issue altogether. Instead, MooTools adds the second part of the equation by creating a new function to replace the instanceof operator: the instanceOf function.

The instanceOf function takes in two arguments: item, which is the object being checked, and object, which should be a constructor function to check against. Unlike the instanceof operator it replaces, though, the instanceOf function properly handles cases like type objects and classes:

// Type Object
new Type('Array', Array);

// make sure that Array is a type object
console.log(typeOf(Array)); // 'type'

// is Array a native instance of Type?
console.log(Array instanceof Type); // false

// is Array an instance of Type in MooTools?
console.log( instanceOf(Array, Type) ); // true


// Class
var Personn = new Class();

// make sure that Person is a class
console.log(typeOf(Person)); // 'class'

// is Person a native instance of Class?

console.log(Person instanceof Class); // false

// is Person an instance of Class in MooTools?
console.log( instanceOf(Person, Class) ); // true

Revamping our examples from the previous section, you'll notice that instanceOf(Array, Type) and instanceOf(Person, Class) now both return true. This tells us that Array and Person are instances of Type and Class respectively—which is exactly what we would want to know.

Like its native counterpart, the instanceOf function works by comparing the constructor of the item argument with the constructor function that's the value of the object argument. Unlike the native instanceof operator, though, instanceOf is aware of the $constructor property and uses this property instead of the regular constructor property as much as possible. The comparison process involves a direct equality test, which means that instanceOf(Array, Type) is somewhat equivalent to Array.$constructor == Type.

I said "somewhat equivalent" because the comparison isn't a one-off process. Like the native instanceof operator, the instanceOf function also does "deep" comparison, so checking whether an object is an instance of some ancestral constructor also works:

new Type('Array', Array);

console.log(instanceOf(Array, Type)); // true
console.log(instanceOf(Array, Function)); // true
console.log(instanceOf(Array, Object)); // true

The creation of the $constructor property is done by the Type constructor (and by the Class constructor for classes). When the constructor function argument is processed by Type, it adds a $constructor property to the constructor function that's used for the instanceOf function. The $constructor property of the constructor function passed to Type is always set to the Type function itself, so that instanceOf will be able to determine that the type object is an instance of the Type constructor.

However, the Type constructor doesn't just add a $constructor property to the constructor argument, but also to the prototype of the constructor argument. In the snippet above, for instance, Type doesn't just set Array.$constructor to Type, but also adds the property Array.prototype.$constructor. The $constructor property of the prototype is then set to the constructor itself, so in our example, Array.prototype.$constructor == Array. This additional prototype property creates one big difference between the instanceof operator and the instanceOf function: the ability to check primitive values.

The instanceof operator, by design, only works if the left-hand side of the expression is an object, not a primitive. If you use a primitive as the value of the left-hand side, it won't work: 'hello' instanceof String evaluates to false. The instanceof operator does not perform type-casting, so primitive values are treated as true primitives and not objects.

However, the instanceOf function doesn't have the same limitation. Because it depends on the $constructor property rather than the true native type of the value, the instanceOf function is able to determine types even for primitive values. In the process of accessing the $constructor property of the value passed, primitives are automatically turned into objects within the instanceOf function, and therefore inherit the $constructor property from their respective type objects. Thus, instanceOf('hello', String) evaluates to true.

Before we move on, though, it's important to note that the instanceOf function also uses instanceof internally as a fallback mechanism in case regular $constructor checking doesn't work. This is an important thing to remember because of a special group of types that don't have type objects, which we'll encounter in a bit.

JavaScript gives us the typeof operator for detecting the types of our values. But as we saw earlier in this chapter, the native typeof operator leaves a lot to be desired. Its replacement from the MooTools type system, the typeOf function, does a better job at detecting the types of values as well as differentiating among the actual types of objects.

Unlike the instanceOf function, though, which only depends on the constructor and $constructor properties of the value passed, the typeOf operator uses a couple of different ways to properly detect the type of a value. At the top of the list is the use of type objects to pass special functions to their instances, which are called family methods.

A family method is a special private method that's added by the Type constructor to the prototype of the type object that's used to return the type of the object. It is a very simple function that simply returns the lowercase name of the type as a string. When creating new Type('Array', Array), for example, the Type constructor adds a new method called $family to Array.prototype, and this new method simply returns the lowercase equivalent of the name passed to the Type constructor. Thus, Array.prototype.$family returns 'array' when invoked.

This family method is then invoked by the typeOf function to return the type of the value. Because the family method is added to the prototype of the type object directly, all instances of the type will therefore inherit the same family method. So detecting the type of an object is as simple as calling its $family method. In the case of arrays, for instance, doing [].$family() or typeOf([]) returns 'array' for both cases—which is the actual type of the object. The typeOf operator simplifies this process of calling the $family function of the object by doing it automatically.

You might be asking then, "What's the use of calling typeOf then, when I could just invoke the $family method directly?" Well, the first answer is because typeOf is part of the private API—and like many things in the private MooTools API, it's bound to change eventually. Making direct calls to this method makes your code prone to breakage when new versions of the library come out—especially ones that change the internal API dramatically (and it happens!).

But even if we're absolutely sure that it will never break—and that's highly unlikely—there's an even bigger reason why you should not call the $family method directly:

// regular object
var obj = {};

// typeOf
console.log(typeOf(obj)); // 'object'

// obj.$family
console.log(obj.$family()); // this will throw an error

In this snippet, passing the obj variable to typeOf works as expected, and we get the proper type—'object'—as the return value. However, if we try to do obj.$family(), we'll get an error—because obj has no method named $family.

Remember that the $family method is inherited by objects from their type objects, and it is added directly to the prototype of the type object via the Type constructor. However, some objects don't have a $family method because they don't inherit the method from their type objects. In fact, it's just not the case of not inheriting the method; it's a case of not having actual type objects in the first place!

Some native constructors, Object being the most notable, are not turned into type objects by the MooTools type system. A few of them aren't turned into type objects because they're not used in common programming tasks, while some aren't converted to impose restrictions. The Object constructor is the chief example of that second reason: it isn't turned into a type object to prevent extension of Object.prototype.

One other important set of types are those with no real constructors. For instance, argument objects, which are created for use inside functions, don't have a corresponding constructor—there's no Argument constructor in JavaScript. Other notable examples are DOM objects like textnodes and whitespaces, which also don't have constructor functions.

The MooTools type system recognizes these types even though they don't have corresponding type objects. However, it presents a little challenge to using $family directly. Because not all values inherit a $family method, we can't depend on this function alone to detect the type of a value. So, as in the case of our example above, we can't call the $family method directly because there's a risk that the object might not have the method to begin with.

This is the prime reason why the $family method should not be used as a replacement for typeOf. The typeOf function is smart enough to know whether the value in question has a $family method that can be called and does so if that's the case. If there's no $family method present, though, it uses another technique to detect the type.

So what's this other technique? It's called duck typing, and its name comes from the common saying: "If it walks like a duck and talks like a duck, then it must be a duck."

Duck typing bases its assumption of an object's type according to the structure of the object. As long as the object's properties and methods match the declared properties and methods for a type (walks like a duck and talks like a duck), it's considered to be of that type (it must be a duck). Duck typing is commonly used in dynamically typed languages to support substitutability. Because of the loose requirements of duck typing, you can design your code in such a way that it accepts objects of any type as long as they have a particular method or property.

However, very loose duck typing can't be applied to a type system directly, since we'd risk having false positives. For example, you can check for the existence of a length property to find out whether an object is an array, and it'll work for the most part, but it'll also think that string objects, argument objects, and element collections are arrays, since all of those appear to be array-like.

For duck typing to be really useful, the criteria for considering an object to be a type need to be very strict. The typeOf function uses several strict criteria to determine the type for values that have no type objects. Argument objects, for example, are tested not only for the presence of the length property, but for the existence of a callee property as well.

This, of course, isn't perfect and is easily bypassed by cunning manipulation of code. The code typeOf({length: 1, callee: 1}), for example, will return "arguments" even if what you have is not really an argument object. Unfortunately, there's nothing we can do about this, since duck typing is the only other solution we can use for values with no corresponding type objects. Thankfully, though, we can use the idea of duck typing to craft code that doesn't rely entirely on the specificity of type to do its job.

Take note that family methods take precedence in the typing process for typeOf. Duck typing is a fallback technique used only for objects with no corresponding type objects. And if these two techniques don't work, the typeof operator is used by the typeOf function as a last resort.

When working with native JavaScript, adding new properties or methods to existing types is done by augmenting the prototype object of their respective constructor. If we want to add a new repeat method for strings, for instance, we have to do something like this:

var str = 'hello';

console.log(typeOf(str.repeat)); // 'null'

String.prototype.repeat = function(times){
        var arr = [];
        while (times--) arr.push(this);
        return arr.join(''),
};

console.log(typeOf(str.repeat)); // 'function'
console.log(str.repeat(3)); // 'hellohellohello'

At the start of the code, the repeat method doesn't exist yet, so str.repeat is typed as 'null'. We then declare this new method by assigning a function to String.prototype.repeat. Afterwards, we check whether the repeat method is now available for strings, and we use it to repeat the string 'hello' three times.

We looked at this technique of augmenting the prototype property of a class in a previous chapter, and we saw how it's not the best way to add new members to a class. Adding new members directly to the prototype limits the additional features MooTools can offer, and the verbosity of the code could mean having to manage really complex declarations in the future. Instead of doing it that way, we learned that it's better to use the implement class method, which replaces the need for direct augmentation and streamlines the process of implementing new members.

Like classes, type objects also have an implement method, and we can use this method to rewrite the previous snippet:

var str = 'hello';

console.log(typeOf(str.repeat)); // 'null'

String.implement({

    repeat: function(times){
        var arr = [];
        while (times--) arr.push(this);
        return arr.join(''),
    }

});

console.log(typeOf(str.repeat)); // 'function'
console.log(str.repeat(3)); // 'hellohellohello'

The implement methods of classes and type objects are used similarly: implement accepts as an argument an object literal that describes the properties and methods you want to add and it loops through each of these members and adds them to the prototype.

While they appear to be the same function from the outside, the implement method of objects is not the exact same method as the one for classes. In the chapter on classes, we discovered the various internal features of the class implement method, including dereferencing, code wrapping, and mutator management. The type implement method also has some powerful internal features, although overall, it is much simpler than its class counterpart.

One of the more noticeable differences is that the type implement method does not do wrapping:

var myFn = function(){
    console.log('fn'),
};

// class
var Person = new Class();

Person.implement({
    method: myFn
});

var shiela = new Person();

console.log(shiela.method == myFn); // false

// type
String.implement({
    method: myFn
});

var str = 'hello world';

console.log(str.method == myFn); // true

In the first part of this snippet, we compare the method method of the Person class with the original myFn function using the line shiela.method == myFn. The result is false, which is expected because the implement method of classes wraps the original function in order to add additional class features. In the case of types, however, the methods added through implement are not wrapped but are added directly to the type's prototype object. Thus, when we do str.method == myFn, we get true—and this tells us that the methods are indeed the same function.

Newly added methods are not wrapped by the type implement method because the wrapper is no longer needed. Classes need method wrappers in order to implement protected methods and this.parent, but type objects don't support (or need) either of these features. Moreover, type objects are created using existing constructors that often already have existing members in their prototypes, and wrapping these existing methods might break them.

In the previous chapter, we learned about the protect method, which is used to implement protected methods in classes. The protect method has another use, in fact, and that is to protect a native method from being overridden. Consider the following example:

// original method
String.implement('method', function(){
        console.log('Original'),
}.protect());

'hello'.method(); // 'Original'

// override original
String.implement('method', function(){
        console.log('Override'),
});

'hello'.method(); // 'Original'

Here we first implemented a new String method called method which simply logs 'Original' in our console. However, we also called the protect method of the function value we're passing to implement, making our new method protected. When we tried to override this original method by calling implement again with a new method definition, our original function wasn't overridden, which is why we still get the same string in our logs.

The protect method is therefore very handy for making sure that native methods that browsers already implement aren't overridden by the user. By default, all the native methods for native objects defined by the ECMAScript specification are protected by MooTools, and therefore cannot be overridden by the user.

Type objects support a special feature called aliasing, which is simply reimplementing an existing method using another name. It is done using the alias method, which takes two string arguments: the name for the new method and the name of the old method to be aliased.

var str = 'howdy';

// implement the original
String.implement({

    repeat: function(times){
        var arr = [];
        while (times--) arr.push(this);
        return arr.join(''),
    }

});

console.log(str.repeat(2)); // 'howdyhowdy'

// alias repeat
String.alias('again', 'repeat'),
console.log(str.again == str.repeat); // true

console.log(str.again(2)); // 'howdyhowdy'

In this example, we aliased the original repeat method of the String type simply by calling String.alias('again', 'repeat'). The alias method then takes the original function value of String.prototype.repeat and copies it to String.prototype.again. The result is that the two methods now point to the same function, making it possible to substitute calls to one for the other.

Aliasing is a very useful feature for creating shortcuts for commonly used methods with very long names. The Array method forEach, for example, is automatically aliased by MooTools into the each method, which is shorter and easier to type. You can do the same for other methods in any type objects to shorten your code and make it cleaner.

An important thing to note, though, is that aliasing uses implement internally, and all aliases methods are true references. Therefore, if you override the original method, your alias will not be updated:

var str = 'hi';

// implement original
String.implement({

    original: function(){
        console.log('hello'),
    }

});

String.alias('copy', 'original'),
console.log(str.copy == str.original); // true

str.original(); // 'hello'
str.copy(); // 'hello'

// override original
String.implement({

    original: function(){
        console.log('woot!'),
    }

});

console.log(str.copy == str.original); // false

str.original(); // 'woot!'
str.copy(); // 'hello'

In the first part of the snippet, both the original method and its aliased copy method point to the same function, and therefore act as the same method. However, when we reimplement the original method, the aliased copy method doesn't get updated.

Another useful feature that's related to aliasing is called mirroring. While aliasing allows you to reimplement a method on a type, mirroring allows you to copy any implemented method from one type to another. To perform mirroring, we use the mirror method of a type, which accepts a single argument that is a type object. Take a look at the following snippet:

var arr = [], str = 'hello';

console.log(arr.log); // undefined
console.log(str.log); // undefined

// make String "mirror" Array
Array.mirror(String);

// implement log on array
Array.implement({

    log: function(){
        console.log('log called.'),
    }

});

console.log(arr.log == str.log); // true

arr.log(); // method called.
str.log(); // method called.

The important line in this snippet is Array.mirror(String). This tells the type system that String is a "mirror" of Array, and any methods implemented on Array from then on should also be implemented on String. Because of this mirroring, the log method we implemented on the Array type is also implemented on String.

Mirroring makes it possible to automatically implement methods across multiple types. A single type can have multiple mirrors, which makes implementing the same method among many types easier and cleaner. The Array type, for instance, could have mirrors for other array-like objects, so that any method that's implemented for arrays would also be available to these objects.

It's the job of the implement method to manage mirrors. When the implement method of a type is called, it not only adds the properties and methods to the type object's prototype, but also checks whether the type has mirrors. The implement method then adds the properties and methods to these mirrors, making sure that the members are available to these types as well.

Because mirroring is managed by implement, only those members that are added after the mirror was declared would be automatically added. Existing properties and methods aren't copied, so we have to do that manually if we want to copy them. For instance, even though String was added as a mirror of Array, only the methods that were added via implement after the declaration would be copied—like the log method. Existing array methods, like splice or push, aren't copied automatically.

Another thing to consider is that mirrors aren't reciprocal: implemented methods on a type will be implemented on all its mirrors, but implemented methods for the mirrors aren't added for the type. In the example above, any method implemented on Array after the mirror declaration would be copied to String, but any method implemented on String won't be copied to Array. If you want reciprocal mirrors, you'll have to declare mirrors for both types.

The mirror method of type objects isn't actually limited just to type object arguments. We can also pass a callback function that will be invoked for every item that's implemented:

var callback = function(name, method){
    console.log(name);
};

Array.mirror(callback);

Array.implement({

    logA: function(){},

    logB: function(){}

});

In this example, we declared the callback function to be a mirror for Array. For every item processed by implement, the callback function will be invoked and passed two arguments. The first argument, name, is the key of the item being implemented and the second argument, method, is the actual function. For this code, the callback function will be invoked first with the arguments 'logA' and a function, and then with 'logB' and another function.

Function mirrors are especially useful in cases when you want to process the method first before implementing it on another type. For example, the MooTools Elements type uses a function mirror to transform methods from Element into methods that work on an array-like object. We'll learn more about this particular trick in Chapter 8 on the Element type.

We first saw the use of the extend method in the chapter on class extras. This method is inherited from Function.prototype, and allows us to augment function objects directly:

var fn = function(){};

console.log(fn.prop); // undefined
console.log(fn.item); // undefined

fn.extend({

    prop: 'property',

    item: 'item'

});

console.log(fn.prop); // 'property'
console.log(fn.item); // 'item'

Instead of declaring the properties prop and item directly using an assignment statement, we passed an object to the extend method of fn containing these new properties. The result of using extend is the same as a normal assignment, but it's cleaner and more organized.

Classes, being abstracted constructor functions, also inherit the extend method from Function.prototype. Type objects, on the other hand, also have an extend method, but it's an overriding method that's inherited from Type.prototype. The original extend method from Function.prototype and the one from Type.prototype have the same external API—they both accept an object argument and they both perform the same extension operation using direct augmentation. Type.prototype.extend has an additional feature that's not present in its Function.prototype counterpart—but we'll talk about this in the next section.

One important use of the extend method that we saw before was to add static methods to classes. We can also do this with type objects:

Array.extend({

    identity: function(){
        console.log(this === Array);
    },

    log: function(){
        console.log('Hello'),
    }

});

Array.identity(); // true
Array.log(); // 'Hello'

Here we added two static methods to Array, identity, and log. The identity method is used to show that the this keyword in the static method is bound to the type object, while the log method is a simple method that logs the string 'Hello'. Though these two are very trivial examples, they tell us that static methods work the same for type objects as they do for classes: they're actually methods of the type object itself rather than its instances.

There's a special group of static methods, though, that are particularly important in MooTools and they're called generics. A generic is a static version of an instance method that can be applied to any object. Generics are handy for using methods from one type on another type without having to directly call the method from the prototype.

The best way to explain generics is with an example. In the section on array objects in this chapter, I mentioned that array methods are intentionally generic in the sense that they can be used on any object. For example, we can use the push method of arrays to add a new item to an array-like object:

var obj = {0: 'pizza', length: 1};

console.log(obj.length); // 1

// invoke the push method of arrays
Array.prototype.push.call(obj, 'soda'),

console.log(obj.length); // 2

In order to access the push method, we had to access the method via Array.prototype. We then used the function method call, passing in the arguments obj and 'soda'. The first argument becomes the value of the this keyword inside the push method, while the second is the actual item that will be pushed into the object. The result is that the string 'soda' is pushed into our array-like object, and its length property is automatically incremented.

Now imagine that you need to use the push method on that particular object several times through your code. Accessing it via Array.prototype is unnecessarily verbose, and doing it multiple times leads to unnecessary repetition—not to mention having to use the call method, too. To really make these methods useful, we need an easier way to access them.

This is where generic methods come in. Take a look at this version of the previous example:

var obj = {0: 'pizza', length: 1};

console.log(obj.length); // 1

// invoke the push method of arrays
Array.push(obj, 'soda'),

console.log(obj.length); // 2

We replaced the original call to Array.prototype.push.call(obj, 'soda') to Array.push(obj, 'soda'). Array.push is a generic method. Using this method is the same as calling Array.prototype.push.call, and it expects the same arguments. The first argument is always the this keyword value for the method, and the arguments after that are the actual arguments for the method. The result is the same, but the actual invocation pattern is shorter than our original example.

MooTools automatically creates the generic versions of the methods of all native types. The string instance method split, for example, is available via the String.split generic, while the regexp method test is accessible via RegExp.test. All generic methods have the same invocation signature: the first argument is always the this keyword value, and the arguments after that will be the actual arguments passed to the method.

The implement method also creates generic methods automatically. Any method you add using the implement method would have a corresponding generic method:

console.log(typeOf(Array.log)); // 'null'

Array.implement({

    log: function(){
        console.log('Hello'),
    }

});

console.log(typeOf(Array.log)); // 'function'

Array.log(); // 'Hello'

Generic methods are used heavily in the MooTools framework. In fact, MooTools forgoes extending Object.prototype by implementing all additional Object methods as generics. We've already encountered some generics used inside MooTools in the previous chapters, like Array.slice and Object.merge, and we'll encounter more of them as we go along.

Another set of important static methods are the from methods, and there are four of them:

String.from takes any argument and returns the string value of the argument. The call String.from([1, 2, 3]), for example, returns '1,2,3'.

Number.from takes any argument and uses parseFloat to change the argument to a number value. It then returns that value as a number, or null if it can't be turned into a proper number.

Array.from takes any argument and returns an array. If the argument passed is already an array, it returns the argument without modification. If the argument passed is an array-like object, array.from turns it into a true array before returning it. If the argument is neither an array nor an array-like object, it returns a new array containing the argument. For example, Array.from('hello') will return ['hello'].

Function.from takes any argument and returns a function. If the argument passed is already a function, function.from returns it without modification. Otherwise, it returns a new function that returns the passed argument: Function.from('hello') will return function(){ return 'hello' }.

We already saw Array.from in Chapter 5, and we'll see it—and the other from methods—again throughout this book.

As an example, we'll create a new type called a table. A table is a wrapper for the basic JavaScript object that supports getters and setters, as well as other utility methods. Before we actually implement it, let's see an example of its usage:

var table = new Table();

// setting values
table.set('item', 'pencil'),
table.set({'fruit': 'banana', 'person': 'shiela'});

// accessing objects
table.get('item'), // returns 'pencil'
table.get('item', 'fruit'), // returns {item: 'pencil', fruit: 'banana'}
table.get('event'), // returns undefined

// removal
table.set('event', 'birthday'),
table.get('event'), // returns 'birthday'

table.remove('event'),
table.get('event'), // returns undefined

// membership
table.hasKey('item'), // returns true
table.hasValue('banana'), // returns true
table.keyOf('pencil'), // returns 'item'

// keys and values
table.keys(); // returns ['item', 'fruit', 'person']
table.values(); // returns ['pencil', 'banana', 'shiela']
table.length(); // returns 3

// traversal
table.each(function(item, key){
    console.log(key + ': ' + item);
});

/*
    item: pencil
    fruit: banana
    person: shiela
*/

Unlike a basic object, the items in a table aren't accessible from the table object directly via dot notation, but are accessible only using the get and set methods. We'll also have a remove method for removing items from the table, and three membership methods, hasKey, hasValue, and keyOf, to check whether specific keys or values are present in the table. Finally, we have the utility methods keys, values, and length to give us more information regarding the table itself, and an each method for table traversal.

This sounds like a very complex type, but it's actually pretty simple to implement as we'll see through this section. All the utility functions we need to implement this are already available through native JavaScript functions and MooTools language additions, and creating this new type will be quite easy.

The first thing we need to consider, though, is the constructor. Unlike classes, type objects make no distinction between constructors and initializers. In fact, there are no initializers for type objects: the constructor function acts both as object constructor and initializer.

There are two main reasons why this design was implemented for the type system. First is that native type constructors don't separate constructors and initializers, so it was deemed necessary to follow this standard in the MooTools type system. The second reason is more important: it is because type constructors were created for the purpose of initializing basic data types, which should be much simpler and more lightweight than classes. If you want a full-featured object system, use a class; otherwise, use a type. (We'll talk more about these distinctions in the last part of this section).

Since the special constructor features like automatic dereferencing available to classes aren't implemented for type objects, we need to make sure we're mindful of these issues. Dereferencing is the biggest of these issues, and we have to make sure that we create any object-based property inside the constructor itself, rather than declare them in our prototype.

In our table type, we'll need one of these object properties called $storage. Since it's an object property, we need to set it inside our Table constructor:

function Table(){
    this.$storage = {};
};

This is the foundation of our table type: the Table constructor. We used a function definition rather than a declaration since we want our constructor to have a proper name property—and also since this is recommended MooTools style. Inside the constructor, we have a line that creates a $storage property for the instance, which will then be used to store the items for our table. Because $storage is an object, we set it inside the constructor rather than in Table.prototype so that each table instance will have a unique storage object.

In order to make our Table constructor similar to native types, we need to give it the ability to be called as a regular function. If you recall from earlier in this chapter, we found out that native constructors could be called as regular functions, and they either perform type casting or create new instances. We'll follow the latter: if our Table constructor is called in conjunction with the new keyword, it'll act as a regular object constructor; otherwise, it'll return a new Table instance.

function Table(){
    if (instanceOf(this, Table)){
        this.$storage = {};
    } else {
        return new Table();
    }
};

We modified our constructor by adding an instanceOf check to see if the new keyword was used. If our Table constructor was called with the new keyword, the value of this inside the function will be an instance of the Table type. On the other hand, calling Table as a regular function sets the this keyword differently, so we'll need to instantiate and return a true instance of the Table type.

Now that the constructor is ready, all we need to do is turn it into a type object, and that's as simple as passing it to the Type constructor:

function Table(){
    if (instanceOf(this, Table)){
        this.$storage = {};
    } else {
        return new Table();
    }
};

new Type('Table', Table);

var table = new Table();

console.log(typeOf(table)); // 'table'

With the constructor done, it's now time to implement our getter and setter methods. Instead of adding these methods directly to Table.prototype, we'll use the implement method so that our code is more organized.

The methods themselves are very simple:

Table.implement({

    set: function(key, value){
        this.$storage[key] = value;
        return this;
    },

    get: function(key){
        return this.$storage[key];
    }

});

The first method is set, and it takes two arguments: a string key, which is the identifier for the item, and value, which can be any value associated with the key. Storing the value in the $storage itself is as simple as assigning the particular key to the value. The get method, on the other hand, requires only one argument, key, which is the key of the item being accessed, and returning the value from the storage is also done using the simple access expression.

However, if you look back at the example use, you'll notice that the set and get methods have two forms. In the first form, they're used like the simple declaration above: set requires two arguments, while get requires a single one. In the second form, they're used to perform multiple operations. The set method in this form requires only one argument, an object literal, and it adds all the items from this object to the storage. Meanwhile, the get method in the second form accepts multiple key arguments, and returns an object containing the results.

To implement these new forms, we can modify our methods so they'll accept different argument types. The set method would have to be modified to check the first argument: if the argument is a string, it's used as a key and the second argument is used as the value, and if it's an object, the method should loop through the object and add each item to the internal storage. The get method, on the other hand, will have to check for the number of arguments and return either a single value or an object containing multiple key-value pairs depending on the number of key arguments passed.

It sounds like a very complicated task to add these additional features. Fortunately, MooTools already has it covered with two function decorators we can use to transform our set and get methods. The first is the overloadSetter decorator, which takes a function with the signature fn(key, value) and gives it the ability to accept object literal arguments, such as fn({key: value}). The second decorator, overloadGetter, takes a function with the signature fn(key) -> value, and turns it into a function that can accept the signature fn(key1, key2, ...) -> {key1: value1, key2: value2, ...}.

These two decorators are implemented as function methods, and using them for our functions is as simple as invoking them in our declaration:

Table.implement({

    set: function(key, value){
        this.$storage[key] = value;
        return this;
    }.overloadSetter(),

    get: function(key){
        return this.$storage[key];
    }.overloadGetter()

});

Just by adding these invocations, we've transformed our set and get methods into methods that take different argument types. With this declaration, our methods are now usable in the two forms we saw in the initial example.

Finally, we add the remove method, which deletes items from the storage:

Table.implement({

    remove: function(){
        var storage = this.$storage;
        Array.from(arguments).each(function(key){
            delete storage[key];
        });
    }

});

Like our decorated get method, the remove method can take multiple key arguments. Unlike get, though, we didn't decorate remove but instead used very simple code to implement the method. First, we created a local variable storage so we could access the internal storage object from inside our callback function. We then used the Array.from generic to transform the arguments object into a true array, and finally we looped through each of the arguments using the each method and deleted them from the storage. The result is a cleanly implemented remove method that accepts multiple arguments.

Next on our list of methods are the three membership methods: keyOf, hasValue, and hasKey. The keyOf method takes a single argument, value, and returns the key associated with that particular value, while the hasValue and hasKey methods check whether a particular value or key exists in the table.

Let's implement the easiest one first: hasKey. If you recall our discussion on objects, we learned that if we try to access a nonexistent property of an object, we'll get the undefined value. We can therefore implement hasKey simply by checking whether a particular key in our storage object is equal to the undefined value:

Table.implement({

    hasKey: function(key){
        return this.$storage[key] !== undefined;
    }

});

The next two methods, keyOf and hasValue, are trickier. Since they operate on values rather than keys, we have no way to directly access them through our storage object. What we need to do is to use a traversal loop to go through each of the items in our storage and compare their value with the argument.

The hasValue method is easier to implement, since we'll simply have to check if the particular value exists in our storage object, regardless of which key is associated with it:

Table.implement({

    hasValue: function(value){
        var storage = this.$storage;
        for (var key in storage){
            if (storage[key] === value) return true;
        }
        return false;
    }

});

Inside our hasValue method, we loop through each item in the storage object using a for-in loop. For every item we go through, we compare the value of the item with the value argument passed to our method. If we get a match, we immediately halt execution of the function by returning true. If the loop finishes without finding any matches, we fall back to a return value of false.

The keyOf method is similar to the hasValue method, but instead of returning a boolean, we return the actual key associated with the object, or null if there's no such key:

Table.implement({

    keyOf: function(value){
        var storage = this.$storage;
        for (var key in storage){
            if (storage[key] === value) return key;
        }
        return null;
    }

});

We're almost done with our Table type, but we need to implement a couple more methods. Thankfully, they're all similar to our previous item-traversing functions, so it will be very easy to implement them.

Two of the methods we still need to implement are keys and values, which deal with the keys and the values as groups. The keys method returns all the keys of the items in a table, while the values method returns the values of these items:

Table.implement({

    keys: function(){
        var storage = this.$storage;
        var results = [];
        for (var key in storage) results.push(key);
        return results;
    },

values: function(){
        var storage = this.$storage;
        var results = [];
        for (var key in storage) results.push(storage[key]);
        return results;
    }

});

We introduce a new variable in these methods called results, which is an array the keys and values are pushed into. Like hasValue or keyOf, both methods require a traversal loop to iterate through the items in the storage object. For each pass of the traversal loop, the methods push the current key or value into the results array. At the end of the methods, we return the results array, which then contains the needed values.

For the length method, we need to create a method that returns the number of items in the table. One way to do this is through another traversal loop, with an accumulator variable that is incremented with each pass through the loop. But a much simpler way is to reuse the keys (or values) method:

Table.implement({

    length: function(){
        return this.keys().length;
    }

});

Instead of writing another traversal loop for length, we simply invoked the keys method to retrieve an array of keys and then return the length of the array. This shortcut is possible since the number of keys in the internal storage would be equal to the number of items it contains.

Finally, we need to implement the last method: each. Like the array method of the same name, the each method of our Table type accepts a callback function that will be invoked for every item in the table as well as an optional bind argument that will be the this keyword value for the callback function. The callback function will receive three arguments when invoked: the current value, the current key, and the table itself.

Table.implement({

    each: function(fn, bind){
        var storage = this.$storage;
        for (var key in storage) fn.call(bind, storage[key], key, this);
        return this;
    }

});

Table.alias('forEach', 'each'),

As with our previous methods, we use a for-in loop to traverse our storage object. For each item in our storage, we invoke the callback function fn using the call method, binding the object value of our bind argument and passing in the current value, the current key, and the table itself. Since we don't need to return any special value for this method, we simply return the table itself at the end of the function. We also add an alias, for the each method called forEach in order to conform to the native name of the method.

Now that we've implemented all the necessary methods for our Table type, let's combine all our snippets into our final code:

function Table(){
    if (instanceOf(this, Table)){
        this.$storage = {};
    } else {
        return new Table();
    }
};

new Type('Table', Table);

Table.implement({

    set: function(key, value){
        this.$storage[key] = value;
        return this;
    }.overloadSetter(),

    get: function(key){
        return this.$storage[key];
    }.overloadGetter(),

    remove: function(){
        var storage = this.$storage;
        Array.from(arguments).each(function(key){
            delete storage[key];
        });
    },

    hasKey: function(key){
        return this.$storage[key] !== undefined;
    },

    hasValue: function(value){
        var storage = this.$storage;
        for (var key in storage){
            if (storage[key] === value) return true;
        }
        return false;
    },

    keyOf: function(value){
        var storage = this.$storage;
        for (var key in storage){
            if (storage[key] === value) return key;
        }
        return null;
    },

    keys: function(){

var storage = this.$storage;
        var results = [];
        for (var key in storage) results.push(key);
        return results;
    },

    values: function(){
        var storage = this.$storage;
        var results = [];
        for (var key in storage) results.push(storage[key]);
        return results;
    },

    length: function(){
        return this.keys().length;
    },

    each: function(fn, bind){
        var storage = this.$storage;
        for (var key in storage) fn.call(bind, storage[key], key, this);
        return this;
    }

});

Table.alias('forEach', 'each'),

It looks good, right? Using what we've learned about the Type constructor and type objects, we were able to implement a totally new object type. The simplicity of the MooTools type system is apparent in this sample code: our code is clean and organized, the API itself is easy to follow and understand, and the results are awesome enough to warrant real-life usage.

There is, of course, room for improvement. Our Table type is fine as it is, but still has some issues that need fixing. A particular improvement that I want you to figure out is how to limit items to only those that are directly defined through set. For example, calling table.get('constructor') will always return a value, even if we never set a 'constructor' item. This is because our internal storage object inherits several properties and methods from Object.prototype, and these members are also accessible to our methods. The easiest way to solve this would be to add checks using hasOwnProperty in our methods—and I'll leave it to you to fix the code accordingly.