the bind function

John Resig has page Learning Advanced JavaScript to explain how the following script works.

// The .bind method from Prototype.js 
Function.prototype.bind = function(){ 
  var fn = this, args = Array.prototype.slice.call(arguments), object = args.shift(); 
  return function(){ 
    return fn.apply(object, 
      args.concat(Array.prototype.slice.call(arguments))); 
  }; 
};

His explanation is wonderful. And this piece of code is simple, powerful. But it maybe still hard for anyone to understand without any explanation. So I refactored it as follow, and add one use case.

Function.prototype.bind = function() {
    var function_to_be_bound = this;
    //convert argements into a real array
    var args = Array.prototype.slice.call(arguments); 
    //the first element in the array is the context_object to be bound to
    var context_object = args.shift();
    //the rest of elements in the array is the prefilled parameter
    var binding_parameters = args;

memoried function

 Function.prototype.memorized = function(key) {
     this._values = this._values || {};

curry function

Function.method('curry', function() {
    //arguments can not be passed in to closure function
    //var l = arguments.length;
    //var args = [];
    //for (var i = 0; i < l; i++) {
    //    args[i] = arguments[i];
    //}
    var args = Array.prototype.slice.apply(arguments);
    var original_function = this;

Does it matter for an object to know its constructor?

We all knows that javascript inherit the functionality from its constructor. It is important to understand the concept every object has a secret link to constructor's prototype. How about constructor? Does a object know who is its constructor? Let's see a simple example

function Person() {
  alert(this.constructor.name); //Person
  this.constructor.count++; // reuse its constructor as a name space to prevent name polution
};

4 Equals, Reference Type, Value Type

The very fundamental design in .net clr is that type system is classified into two type, reference type and value type. This design decision has profound implication on the .net. One examples is to test the equality between objects.
Basically we have two kinds of comparison, identity comparison(whether two object has the same identity), semantic comparison(whether two object means the same thing, most people refer it as value equality comparison, I use “semantic” because value of reference type is a reference, even the values of reference typed variable are different, it is possible that they mean the same thing in semantics). Since we have the two different type, this makes things complicated. For example, can we compare the “value” of reference type, or can we compare the reference of value type. If there had been only reference type, if there had been no value type, the .net world will be simpler. Why we need two types? This is a deep question, lots of this topics has been covered in a book “CLR via C#”. Basically, this a consideration of memory efficiency and performance. What we need to know is that the value of reference type is reference, the value of value type is value.

Reference type identity comparison

To do identity comparison for reference type, we should call Object.ReferenceEquals(objA, objB), or you can use shortcurt operator “==” like “objA == objB”. The following source code shows that ReferenceEquals and == operator is the same.

public class Object 
{
   [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
   public static bool ReferenceEquals (Object objA, Object objB) {
       return objA == objB; 
   }
}