Wednesday, April 13, 2016

Prototypal inheritance in Javascript

Overview

Javascript is not a classical language, meaning that it doesn’t have class. However, this doesn’t mean that object oriented programming is not supported in Javascript. In fact, all 3 major features of OOP, namely, inheritance, encapsulation and polymorphism, are all possible in Javascript via prototypal inheritance which is built into the language instead of class. Before detailing them further into this article, let’s first list how the 3 major features of OOP are supported in Javascript:

  • Inheritance in Javascript is supported by defining an object as the prototype of another object.
  • Encapsulation in Javascript is supported by its extensible object definition by defining related data and methods on the same prototype object, the latter possible because of first-class function.
  • Polymorphism in Javascript is supported by prototype chain lookup: an object’s behavior is determined at runtime by what is on its prototype chain.

However, the above is only one of the many possible ways to achieve OOP in Javascript, which is coined as pseudoclassical by Douglas Crockford. In his famous book, Javascript: The Good Parts, he listed other ways of doing OOP, such as pure prototypal, functional and building objects via parts, thanks to the flexibility of object in Javascript. On contrary, an object-oriented languages that relies on class to achieve OOP, such as Java and C++, as well as this way of doing OOP, are called classical.

Even though Javascript supports pure prototypal OOP and it seems to be the original design idea, pseudoclassical usage of Javascript is still the main stream. Many Javascript frameworks, such as Node.js and Google Closure are all promoting psuedoclassical pattern as the paradigm. There are even syntactical sugar that makes Javascript looks more classical. Therefore, this article focuses on the pseudoclassical usage of Javascript based on its prototypal nature. Without further ado, let’s go to some code examples.

Constructor Function

In Javascript, a constructor function roughly maps to class definition** in classical language such as Java. A constructor function is not different from any other function. The only difference is that a constructor function is called with the new keyword. Since there is no language feature to distinguish a constructor function from non-constructor function, it’s conventional to capitalize the first latter of a constructor function’s name, making it look even more like Java.

var Employee = function(firstName, lastName, id) {
    this.firstName = firstName;
    this.lastName = lastName;
    this.id = id;
};

Employee.prototype.printInfo = function() {
    var name = this.firstName + " " + this.lastName;
    console.log("Name: " + name);
    console.log("Id: " + this.id);
};

var securityPerson = new Employee("Jack", "Lee", "0001");

// Name: Jack Lee
// Id: 0001
securityPerson.printInfo();

The above code defines an Employee class which 3 fields assigned via the constructor. It also adds a printInfo method to the Employee class by defining it on the prototype object of the constructor function. Finally, we created an instance of Employee, securityPerson, and calls the printInfo method on it.

Note: The above paragraph uses classical notions such as class, field, instance, etc. which are not accurate in Javascript. However, because most people are most familiar with classical notions, we’ll keep using them to avoid the verbose differentiating explanation every time.

As shown in the above example, the prototype object of the constructor function, Employee.prototype above, is the place where methods of a class are defined. Where as fields are defined directly on the this object inside the constructor function.

When defining a functionin Javascript, the function object runs some code like this:

this.prototype = {constructor: this};

which creates an empty object as the prototype object of the constructor function. This object is not entirely empty as it has a constructor attribute pointing back to the constructor function. The constructor property is not very important, but it makes it easier to find the constructor of an object.

// This will print the constructor function, something like:
// function (firstName, lastName, id) {
//    this.firstName = firstName;
//    this.lastName = lastName;
//    this.id = id;
// }
console.log(securityPerson.constructor);

When a constructor function is called with the new keyword, the Javascript runtime does more then calling the function itself. The following is done in sequence under the hood:

  1. A new object is created that inherits from the constructor’s prototype object:

    var newObj = Object.create(Employee.prototype);
    

    Notice that the Object.create() method is used to assign the prototype to illustrate the process. In reality, the Javascript runtime does something lower level.

  2. The constructor is invoked with this bound to the new object:

    var ret = Employee.apply(newObj, "Jack", "Lee", "0001");
    
  3. The new object is returned. However, if the constructor function returns an object itself, then that is returned instead:

    var securityPerson = (typeof ret === 'object' && ret) || newOjb;
    

Prototype Chain

It’s mentioned in step 1 of how new works that the prototype of the newly created object is set to the prototype object of the constructor function. It’s crucial that we use two slightly different terms here. The prototype of an object is its prototype in the sense of prototypal inheritance. The prototype object of the constructor function is simply an attribute on the function object whose name is “prototype”. The prototype object is used in Javascript to enable the pseudoclassical new syntax, so that the newly created object has its prototype set to it. After an object is created by new, the prototype object of its constructor is no longer relevant.

What matters is the prototype of an object. The prototype is an internal property of an object and should not be modified, although modern browsers all implements the __proto__ pseudo-property that points to an object’s prototype. The __proto__ property should not be directly used by application code, as indicated by its __ prefix. Nonetheless, it’s useful for illustrating prototype chain machenism, so I’ll use it in code samples.

In Javascript, each object has an prototype, which is in turn an object. That object has its own prototype, which is in turn an object again. Following this chain of prototypes, it eventually leads to Object.prototype, which is the prototype object of the Object() constructor and thus the immediate prototype of all objects created via object literal or new Object(). The prototype of Object.prototype is null. For any object, its prototype, its prototype’s prototype, …, all the way to Object.prototype forms a chain called its prototype chain. The prototype chains of all objects in Javascript runtime forms a tree structure.

Note: The tree structure is guaranteed because there can not be loops in the prototype chain, a fundamental invariant enforced by Javascript runtime. One can try to force a prototype chain and the Javascript runtime will certainly throw:
var a = {}, b = {};
a.__proto__ = b;
b.__proto__ = a;
Try the above lines in Chrome results in Uncaught TypeError: Cyclic __proto__ value(…). By the way, the above code runs because Chrome happens to define __proto__ property and make it writable. One should never try to modify __proto__ in application code, as its behavior is only recently standardized and its usage is discouraged.

Here is an example showing the prototype chains:

var securityPerson = new Employee("Jack", "Lee", "0001");
var janitor = new Employee("Robert", "Douglas", "0002");

var printPrototypeChain = function(obj) {
    var chain = 'this';
    var prototype = obj.__proto__;
    while (true) {
        if (prototype === Employee.prototype) {
            chain += " -> Employee.prototype";
        } else if (prototype === Object.prototype) {
            chain += " -> Object.prototype";
        } else if (prototype === Function.prototype) {
            chain += " -> Function.prototype";
        } else if (prototype === null) {
            chain += " -> null";
            break;
        } else {
            chain += " -> ?";
        }
        prototype = prototype.__proto__;
    }
    console.log(chain);
};

// this -> Employee.prototype -> Object.prototype -> null
printPrototypeChain(securityPerson);

// this -> Employee.prototype -> Object.prototype -> null
printPrototypeChain(janitor);

// this -> Object.prototype -> null
printPrototypeChain({x:1, y:2});

// this -> Function.prototype -> Object.prototype -> null
printPrototypeChain(function() { return true; });

// this -> ? -> Object.prototype -> null
// The '?' stands for Array.prototype
printPrototypeChain(new Array(1, 2, 3));

Property Lookup

So why does prototype chain matters? The prototype chain is used when looking up a property on an object. For example, when evaluating an expression such as obj.someProperty, the Javascript rumtime will look for someProperty on obj itself, then following it’s prototype chain to try to find it on obj.__proto__, obj.__proto__.__proto__, until it reaches Object.prototype. If there is no someProperty on obj nor its prototype chain, undefined is returned. This allows an object to inherit its prototypes, thus achieving inheritance and code reuse.

Prototype chain is looked up when getting property but not when setting property. Otherwise, manipulating one object has the side effect of modifying the behavior of other objects with overlapping prototype chain. This is illustrated below:

var securityPerson = new Employee("Jack", "Lee", "0001");
var janitor = new Employee("Robert", "Douglas", "0002");

// Name: Jack Lee
// Id: 0001
securityPerson.printInfo();

// Name: Robert Douglas
// Id: 0002
janitor.printInfo();

janitor.printInfo = function() {
    console.log("I am the janitor!");
};

// Name: Jack Lee
// Id: 0001
securityPerson.printInfo();

// I am the janitor!
janitor.printInfo();

delete janitor.printInfo;

// Name: Jack Lee
// Id: 0001
securityPerson.printInfo();

// Name: Robert Douglas
// Id: 0002
janitor.printInfo();

To summarize, getting a property is done via the prototype chain where as setting/deleting a property is always directly on the object itself.

An Example of Psuedoclassical OOP in Action

Finally, let’s see an example of psuedoclassical OOP in action, illustrating inheritence, encapsulation and polymorphism.

var Employee = function(firstName, lastName, id) {
    this.firstName = firstName;
    this.lastName = lastName;
    this.id = id;
};

// Encapsulation is achieved by bundling related logic into the prototype object
// of the constructor function.
Employee.prototype.printInfo = function() {
    var name = this.firstName + " " + this.lastName;
    console.log("Name: " + name);
    console.log("Id: " + this.id);
    console.log("Annual income: " + this.getAnnualIncome());
};

Employee.prototype.getAnnualIncome = function() {
    // This is to mimic abstract method in Java.
    throw new Error("getAnnualIncome must be implemented by subclass.");
}

var Contractor = function(firstName, lastName, id, hourlyPay) {
    // The way to call super constructor in Javascript is to call it explicitly.
    Employee.call(this, firstName, lastName, id);
    this.hourlyPay = hourlyPay;
};
var tmpCtor = function() {};
tmpCtor.prototype = Employee.prototype;
Contractor.prototyye = new tmpCtor();

// This shows inheritance. The super method is reused with some subclass specific
// customization.
Contractor.prototype.printInfo = function() {
    // The way to call super method in Javascript is to call it explicitly.
    console.log("[Contractor]");
    Employee.prototype.printInfo.call(this);
}

// This shows polymorphism: when getAnnualIncome is called in
// Employee.prototype.printInfo, the exact behavior is determined by the subclass
// at runtime.
Contractor.prototype.getAnnualIncome = function() {
    return 12 * 20 * 8 * this.hourlyPay;
}

var FullTimeEmployee = function(firstName, lastName, id, salary) {
    // The way to call super constructor in Javascript is to call it explicitly.
    Employee.call(this, firstName, lastName, id);
    this.salary = salary;
}
tmpCtor.prototype = Employee.prototype;
FullTimeEmployee.prototyye = new tmpCtor();

FullTimeEmployee.prototype.printInfo = function() {
    console.log("[Full-time Employee]");
    // The way to call super method in Javascript is to call it explicitly.
    Employee.prototype.printInfo.call(this);
}

FullTimeEmployee.prototype.getAnnualIncome = function() {
    return 12 * this.salary;
}

var newMeetingRoomBuilder = new Contractor("Victor", "Johnson", "0003", 20);
// [Contractor]
// Name: Victor Johnson
// Id: 0003
// Annual income: 38400
newMeetingRoomBuilder.printInfo();

var systemAdmin = new FullTimeEmployee("Peter", "Huffman", "0004", 6000);
// [Full-time Employee]
// Name: Peter Huffman
// Id: 0004
// Annual income: 72000
systemAdmin.printInfo();

Thursday, December 31, 2015

Java 8 Resources

Java 8 has been released for more than a year yet I started to learn its new features just two days ago. One reason for my slow adoption is because I focuses mostly in Android programming last year where the new Java 8 features is not available. This is not strictly true though because one can potentially setup bytecode translation to use Java 8 in Android code (link).

During my search for Java 8 resources on the Internet, I found the following resources meritorious. Some of them are through and well-written, whereas others are perfect for building up basic familiarity in short time.

Processing Data with Java SE 8 Streams by Raoul-Gabriel Urma

Part 1
Part 2


5 Minutes Series by IDR Solutions Blog

Lambda
Method Reference
Default Method
Stream

Monday, November 16, 2015

Java Generics Note: Reification vs. Covariance

During my study of Java generics, two terms often comes up are reification and covariance.

Reification means the resolution of a instance's exact type at run time. A type is reifiable if JVM can tell the type given an instance at runtime, otherwise we say the type is unreifiable. All generic types are not reifiable, except when it's a unbounded wildcard type or raw type. This is because the Java compiler erases all type argument information with a procedure called type erasure. On the other hand, array types are reifiable, because the element type is available at run time.

Covariance is a property about deriving a set of types given a set of basic types. For instance, for any reference type T, List<T> and T[] are types of its own. Such a derived set of types is said to be covariant they inherit the type compatibility of the basic types. In this case, List<T> is not covariant, because List<Integer> is not a subtype of List<Object>

To conclude, generic types are unreifiable and incovariant, whereas array types are reifiable and covariant. One might ask, can we have other combination of this properties? Such as a set of types that are reifiable and incovariant, or unreifiable and covariant? To answer this question, one need to first understand an very important property that guides the design of strongly type language, such as Java, which is type-safety. For generic types, it means that the program shall not call List<Integer>'s add() method with a String type argument. For array, it means the program shall not call arr[i] = "foobar" if the type of arr is Integer[].

Generic types such as List<T> is unreifiable, meaning that the runtime can't tell List<String> from List<Integer>. Let's assume that List<T> is covariant, this means that List<String> and List<Integer> will both be a subtypes of List<Object>

List<Object> = new List<Integer>()
List<String> strList = (List&ltString>) intList; // Allowed as a down cast.
strList.add(100);
strList.get(0).length();

The issue happen at runtime. Since List<T> is unreifiable, JVM can't tell that line 3 is wrong, so no runtime exception will be thrown.However, line 4 will fail because Integer doesn't have a length() method (in reality a ClassCastException is thrown because Java compiler adds a cast before calling length()). Therefore, a unreifiable type have to also be incovariant to avoid issues like this.

Monday, March 10, 2014

Auto Margin in CSS

Auto margin is normally used to center an element horizontally. Basically, set margin to auto will cause margin-left and margin-right to be set by browser so that the element is centered horizontally in its containing block. An exception is that margin-left can not be less than 0 in this automatic setting, thus margin-left will not go negative if the width of the element is larger than the width of the containing block.

Auto margin can also be used to center element vertically. This is much rarer though. This happens when the element is absolutely positioned and when top and bottom are set. If that is the case, then the element will be centered both horizontally and vertically in its positioning parent. The difference is that margin-top can be negative but margin-left can not. In other words, when its positioning parent is narrower than itself in width, then it won't be centered horizontally, just as the discussion in previous paragraph. However, when its positioning parent is shorter than itself in height, it will still be centered vertically, by having a negative margin-top. This is useful when you want to have a image background that is always centered even if the view port size is small, as used in the second CSS trick in this article. Notice that the trick in the article has the flaw that when the window is very narrow in width, the background will no longer be centered due to non-negative margin-left discussed above, while it is still fine for the vertical centering no matter how short the window is.

Thursday, February 27, 2014

Ignoring Mouse Event on DOM Element Using CSS 'pointer-events' Property

Yesterday, I was trying to write my simple Javascript tooltip library that can handle customized feature such as tooltip width, orientation of appearance, and also support arbitrary div content. An example page is here.

Basically, the tooltip div element is positioned absolutely and it shall fade in and out when the trigger text's mouseenter and mouseleave events are fired.

The first difficulty is when the trigger text, say a span, span across multiple lines, such as example two. In CSS term, this span has more than one bounding boxes. This is not a problem if the trigger is a block element as a block element has exactly one bounding box. The desired effect is that the tooltip shall appear next to the bounding box that the mouse enters. This can be solved using the getClientRects method to get all the bounding rectangles of an inline element and decide which of them is entered by the mouse.

The second difficulty, which I want to record here, is as follows. Sometime, due to resizing of browser window, the tooltip will cover part of the trigger text. In extreme case, the tooltip will cover up the entire trigger. As a result, when the tooltip covers the trigger, mouseleave event will be fired on the trigger, even if the mouse is still "on" the trigger. Then the tooltip will fade out and the mouseenter will be fired again... Of course, due to browser event handle time, this will not repeat indefinitely, but it still causes an unpleasant glitch, as show in this JS fiddle. After having some discussion on StackOverflow, I finally found the solution, then "pointer-events" CSS property, which can be used to disable any pointer event on the tooltip and let the event go through to the trigger underneath it, as shown in this JS fiddle. This saved my day.

More info can be found here or here.

Sunday, February 23, 2014

Synchronize YouTube videos

Recently, I created a website to synchronize YouTube videos. The idea is that there is a master video and all other videos (called slave videos)  will be synchronized to the master one, in the sense that all playback action on the master video will be reflected on slave videos. This is useful when you want to watch a clip with friends on the other side of the Internet and want to keep your videos play synchronously, even if you pause or seek.

The master page send all playback actions to the web server for temporary storage using standard Ajax. The slave page, on the other hand, need to get these event updates from the server. This is a problem because in the HTTP paradigm, web clients are supposed to send queries to web server, not the other way around. The technology used here is called Comet, which is also called reverse Ajax. The idea of Comet is to allow server to push data to the client. There are multiple methods and framework to achieve Comet. The method I chose is called long polling. As its name suggests, the client need to poll the server continuously with high frequency to ask for update. This is normally done by send a new XMLHttpRequest at the end of the onload callback of the previous XMLHttpRequest. In my code, I add some rate limit so about 2 polling are executed per second. This seems to work but will be harder to scale as the server is being queried continuously, even if there is no event to update.

Saturday, February 1, 2014

Keep the same heights for multi-column layouts in CSS

When having a multiple column layout using float, it is sometimes important to ensure that the columns all having the same height. This is especially important when the columns have backgrounds that are different from the background of the container.

There are quite a few way ensure identical heights: .

Among those, my favorite one is the Flexbox Method by Paul Irish. The flexbox method make use of very large padding and is a pure CSS solution.

Suppose we have a div "container", whose direct children are the columns, then the flexbox only requires extra-large padding and negative margin with the same magnitude, as follows:

HTML
CSS

The mechanism is simple, since the column has a very large bottom padding, the background extends downwards almost infinitely. Then a negative margin make sure that the effective height of the column is not affected. The container will automatically cut of the extra backgrounds so nothing pokes out.