new Constructor VS Object.create

just a quick post about ES5 Object.create performances. While in More ES5 Friendly Patterns paragraph I have described how to use new ES5 features to create instances in a better way, I have never tested directly performances against classic ES3 pattern.

The Benchmark Logic

Pretty simple, create a new object with a "privileged property" plus an inherited one. The test prototype looks like this object:

var proto = {toString:function () {
    return this.name;
}}

The assumption is that somehow the object should be able to return it's name, which is not shared via prototype.

ES3 Game

I hope I don't have to explain this piece of code:

function F(name) {
    this.name = name;
}
F.prototype = proto;

To test above classical pattern, all we need is to confirm this behavior:

var o = new F("instance");
alert(String(o) === "instance");

ES5 Game

Using an updated browser, it should be possible to replicate ES3 behavior via this piece of code:

var o = Object.create(proto, {
    name: {
        value:"object"
    }
});

Right, Object.create comes with much more power than a simple property assignment, but here we are testing a basic task just to analyze what's the outcome, right? Just to be sure about the result:

alert(String(o) === "object");

Optimized ES5 Game

What can we do to improve performances? Avoid global scope look up, the Object constructor, plus use a static/fixed property to cheat the test:

var fixed = {
    name: {
        value: "static"
    }
};

var create = Object.create;

var o = create(proto, fixed);

// the assertion
alert(String(o) === "static");

The Benchmark

Let's put these patterns together inside a closure, execute them 100000 times, retrieving elapsed time.

setTimeout(function () {

var proto = {toString:function () {
    return this.name;
}};

var fixed = {
    name: {
        value: "static"
    }
};

function F(name) {
    this.name = name;
}
F.prototype = proto;

var o;

for(var i = 100000, instance = new Date; i--;) {
    o = new F("instance");
}
instance -= new Date;

for(var i = 100000, object = new Date; i--;) {
    o = Object.create(proto, {
        name: {
            value:"object"
        }
    });
}
object -= new Date;

for(var create = Object.create,
    i = 100000, static = new Date; i--;
) {
    o = create(proto, fixed);
}
static -= new Date;

alert([instance, object, static].join("\n").replace(/-/g,"ms: "));

}, 1000);

The Result

Based on Atom N270 nad testing via Chrome 5 for devs, this is what I read in the alert:

ms: 7
ms: 2325
ms: 2218

The first result goes up to 54ms, reaching 5ms, the second one is pretty much stable while the latest one goes down 'till 1987 ms ...

Conclusion

new Constructor seems to be the best option for those cases where the initialize/init/construct method needs to somehow setup the created instance. Only if we need special Object.create features it is worth it to use it, but if we base a whole framework over Object.create, considering eventually emulations for old browsers, this framework will be inevitably slower than older code. This means that as example a classic Point class option, should still be exactly like this:

function Point(x, y, z) {
    this.x = x;
    this.y = y;
    this.z = z;
}

or eventually like the next one, if we don't need chained methods, neither new before each call:

function Point(x, y, z) {
    return {x:x, y:y, z:z};
}

by my good old AStar algorithm time, the fastest option ever!

Wait A Moment, JavaScript Does Support Multiple Inheritance!

... we are just doing it wrong!

Classical Inheritance? We Have Something Better!

The main limit about multiple inheritance in JavaScript is the presence of "instanceof" operator. In a prototypal based inheritance objects simply inherits from objects, and class keyword is almost meaningless.

// generic constructor
function B(){};

// remember the prototype
var B1proto = B.prototype;

// B instance
var b1 = new B;

// prototype reassignment
B.prototype = {
    constructor:B
};

// remember new prototype
var B2proto = B.prototype;

// B instance
var b2 = new B;

alert(b2 instanceof B); // true
alert(b1 instanceof B); // false

Above snippet demonstrates how inheritance and instanceof are related to the current prototype, rather than the function/constructor itself.
In few words, the function is the implicit init method for the current prototype object. The relation, as we could spot with FireFox, is with the prototype and not the used constructor.

// FireFox exposes __proto__
// will be Object.getPrototypeOf
// in ECMAScript 3.1
b1.__proto__ == B1proto; // true
b2.__proto__ == B2proto; // true

Sure, And What About Multiple Inheritance?

... I am going there, wait another few seconds :D
Since the prototype is the relation, and not the constructor, and since a prototype is nothing but a common Object, we can add whatever method or property we want to this prototype object in order to obtain the hybrid one we are looking for.

function A(){};
A.prototype.name = "A instance";
A.prototype.getName = function(){
    return this.name;
};

function B(){};
B.prototype.name = "B instance";

function C(){};
// default name from B
C.prototype.name = B.prototype.name;
// getName from A
C.prototype.getName = A.prototype.getName;
// new method for C
C.prototype.setName = function(name){
    this.name = name;
};

var c = new C();
c.getName(); // B instance
c.setName("Andrea");
c.getName(); // Andrea

In few words, we can add whatever we want to a prototype object creating exactly what multiple inheritance would create. We still have a problem with instanceof operator, don't we? Well, considering that "instance" concept is something more meaningful in classical inheritance, we could say that it is not possible to emulate multiple inheritance Python like with JavaScript, but we can inject whatever method/property from whatever constructor.prototype, something not possible with Java, PHP, C#, and others ... so are we missing something?

A Basic Object.implement Function Check

Due to the fact we could need to know if an hybrid instance is using this or that method, we could think about an abstract implement method able to tell us if a generic instance constructor prototype, is at least implementing another constructor prototype, considering latter one as an interface. If this is true, we are sure that we can use that instance/object in that way and without problems ... isn't it?

Object.implement = function(o, constructor){
    // Another WebReflection Insane Snippet
    if(o instanceof constructor)
        // nothing to check
        // classical boring stuff
        return true;
    // let's check if things are OK
    var k, b = true,
        // take the instance constructor prototype
        po = o.constructor.prototype,
        // take the implemented prototype
        pc = constructor.prototype
    ;
    // for each property or method
    // in the implemented constructor
    for(k in pc)
        // check if the instance inherited prototype
        // has this method/property as well
        b = b && k in po; //* TOTHINK: */ && (typeof po[k] === typeof pc[k]); //*/
    // if there was nothing to check
    // we cannot say a word ... but ...
    // if instance has every method/property
    // present in the compared constructor
    // prototype, we could say this instance
    // implements this constructor
    return !!k && b;
};

Purist Classical OOP Developers are probably already rolling around the floor in pain and screaming he's f#@*in idiot, but what is the meaning of implement in classical inheritance patterns?
Wikipedia - Interface

Interfaces are used to encode similarities which classes of various types share, but do not necessarily constitute a class relationship

In few words my latest snippet checks if an object contains every method/property defined in another object so, using first example, we could do:

// add noise and chaos with another constructor ...
function D(){};
D.prototype.notInObject = true;

// check Object.implement ...
Object.implement(c, A); // true
Object.implement(c, B); // true
Object.implement(c, C); // true
Object.implement(c, D); // false

Nothing new? Nothing true? Is it clear for everybody? 8-)

On JavaScript Inheritance Performance - One Step Back

Few days ago I wrote a post about this argument, proposing an alternative "best option" way to use an injected parent in each method.

As soon as more developers read my post, more sparkles came out from the fire: true classical inheritance simulation via missed methods in the chain, exception during methods execution that could trap the temporary injected parent, and other interesting stuff again.

At the end of all these tests, benchmark, and libraries evaluation, I decided to step backward about my proposal, making things simple, logic, and extremely fast (as much as possible).

My Conclusions

1. if we inject a parent, we have to change and/or wrap the original method, adding noise in the execution and inevitably more operations to perform (read: less performances)


2. for each inherited metod, even if it is the same of the parent one, we need to add functions and code which means more RAM and less portability


3. more we over-mess the simple JavaScript inheritance stack, less control we'll have for debugging and maintenance


4. using strategies like the one adopted from the YUI library could only add confusion because if we put the instance in a parent method, the super one or the super.super.super (and go on), its parent will be still the original one and if we call this.superclass in the wrong context, results will be always unpredictable for that method (unless we did not write down every specific case, if the instanceof A called that method ... if the instanceof B called that method, etc etc)

Accordingly, the fact we are all lazy developers should not mean we can loose performances, use more RAM, make things more complicated than we need, specially in this Web era where devices with limitations could use our code without problems (iPhone) but only if performances are reasonable and downloaded code size is, again, reasonable.

The new best option to use a parent method

Following the test proposed in the old post, this is how I can obtain best performances even against classical way to use parent methods:

function WRSub(name, age){
    // classical and debug prone parent call (fastest)
    WRClass.call(this, name);
    this.age = age;
};
wr.extend(WRSub, WRClass, {
    // WebReflection parent method call in closure
    // faster than runtime method resolution:
    // WRClass.prototype.toString.call(this)
    toString:(function(toString){
        return function(){
            return toString.call(this) + ": " + this.age;
        }
    })(WRClass.prototype.toString)
});

Summary

I love performances, readable code (big lol from kangax? :P), code portability, logic execution, and all we need is already there in the language.
We do not need to over mess the inheritance chain, the only thing we need is a god way to extend able to understand if the browser is missing hidden methods (toString, etc) and nothing else.
Once we have this good way to extend a constructor, everything else will be fast, readable, debug prone, and compatible with every possible situation, without breaking our neck to understand why that method in that case behaved differently, or that parent did not change as expected, etc etc ... robust, reliable, and fast code? Forget all these parent/$super/superclass implementations, put what you need in a closure to simplify and speed up the code and that's it, as my new benchmark shows where my clean and simple implementation bites every other library, even the classical full namespace way.

News about WebReflection Library

I have added a couple of things which are truly common on daily basis development. You can find a list of all JS 1.6 Array methods to use with whatever list you want, DOM Collections included.

wr.Array.forEach.call(document.getElementsByTagName("div"), function(div, i, collection){
    div.innerHTML = "I am div " + (i + 1);
});

Those are compatible with ECMAScript specs, native performances for updated browsers, best performances for IE and others.
The wr.Object.forIn is the classical for in loop plus hidden methods in IE, something we can use to extend constructors or to inspect objects.
I am considering to put the hasOwnProperty check by default to loop only properties assigned, and not those inherited, but for extending purpose, we need to loop everything.
setInterval and setTimeout are natives or wrapped to support extra arguments as well.
wr.id is the classic method to generate an expando or a unique id for each call while wr.is is a function with all native checks via Object.prototype.toString.

The purpose of the library is not (yet) to substitute other libraries, it is just about basic things we always need, focused on performances, compatibility, etc.
I'll add more, but so far enjoy the extend, now free of bugs since different, the forIn, the is, the id, and current Array implementations.

On JavaScript Inheritance Performance and Libraries Troubles

Update: I have replied to myself and developers in a new post. I would like to say a big Thank You to every developer exposed tests, benchmark, traps, and considerations. Please read my last thoughts about the subject, since I deeply reconsidered my position.
Update: Please do not get me wrong. I have no intention to say that one or any of cited framework, piece of code, library, is not good or fast enough to extend other classes. This post is about maniac optimization based on personal considerations over some deeper analysis to complete in a way the first benchmark.
I am not criticizing libraries, they are great and they offer everything, I am simply showing a specific case, which is particular on purpose, and a specific behavior that, useful or not, could not be respected.

About

Few days ago Ajaxian published a post about JS inherited methods performances via common libraries strategies.
I think the argument is extremely interesting but there's not enough material yet, so here I am with my contribution plus a "best option" proposal.

Why We Need Libraries to Extend Functions

• libraries (should) manage properly the prototypal chain


• libraries (should) make code more elegant/readable


• libraries (should) let us create overrides being able to call parent/super method implicitly if necessary


• libraries are often based over a generic extended "class" or hierarchy and users should be familiar with that way to extend or create classes in order to avoid internal conflicts

Why We Do Not Need Libraries to Extend Functions

• we are performances or bytes maniacs and we are scared by library obtrusive implementations


• we don't trust the library pattern/strategy to extend function - we know a better way to do it simply and quickly


• we would like to create hybrids unmanageable via used library

About above points, let me answer to this question:
"Which Common Code/Library is Good and Fast to Extend Properly?" Considering the YUI approach out of the game, NOT A SINGLE ONE!!!

Tested Libraries in Alphabetic Order

base2, dojo, jClass, MooTools, Prototype, WebReflection (blog proposal), and YUI

About the Test

I tried to create a particular inheritance case.
There is a parent class with a toString and a toLocaleString prototype method.
These methods are particular since they are hidden methods (read: native) and browsers like Internet Explorer do not discover hidden methods even if those have been explicitly assigned.
The extended class should be able to understand the inheritance without problems and produce the expected result, showed in the Ad Hoc example.

Ad Hoc concept and troubles

• Concept: manual inheritance over usable constructors.


• Troubles: requires a bit of skill and parent calls are always explicit.

// manual implementation
// best performances and expected behavior in every browser
function AdHocClass(name){
    this.name = name;
};
AdHocClass.prototype.toString = function(){
    return this.name;
};
AdHocClass.prototype.toLocaleString = function(){
    return "locale: " + this.toString();
};
function AdHocSub(name, age){
    AdHocClass.call(this, name);
    this.age = age;
};
AdHocSub.prototype = new AdHocClass;
AdHocSub.prototype.constructor = AdHocSub;
AdHocSub.prototype.toString = function(){
    return AdHocClass.prototype.toString.call(this) + ": " + this.age;
};

// This is the expected result We would like to obtain
var me = new AdHocSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // locale: Andrea: 30

base2

• Concept: runtime injected parent (called via base) over explicit initialization via init method


• Troubles: every instance calls two functions when initialized: the contructor plus the init method. This slows down performances. At the same time, not every method is inherited properly.

var BaseClass = base2.Base.extend({
    constructor:function(name){
        this.name = name
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var BaseSub = BaseClass.extend({
    constructor:function(name, age){
        this.base(name);
        this.age = age;
    },
    toString:function(){
        return this.base() + ": " + this.age;
    }
});
var me = new BaseSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // ERROR: same as toString both IE and Others

dojo

• Concept: lazy dependencies resolution via the initializer method


• Troubles: the initializer method is not that linear and it is probably the slowest in the list. Sometimes we need to call explicitly the method, as first argument, while sometimes we need to modify the arguments object or create an array to call the parent method. I am not sure I used dojo best practices to replicate the scenario but that's what I found googling for a while (Update: thanks to Eugene Lazutkin I could use a better practice which improved consistently performances). Is the rest fine? Not really, Internet Explorer does not inherit some hidden method. Update: apparently dojo offers different possibilities to extend and "play" with parents, so this is just one of them.

dojo.declare("dojoClass", null, {
    constructor:function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
dojo.declare("dojoSub", dojoClass, {
    constructor:function(name, age){
        this.age = age;
    },
    toString:function($super){
        return this.inherited("toString", arguments) + ": " + this.age;
    }
});
var me = new dojoSub("Andrea", 30);
alert(me);                  // Andrea: 30 - not in IE
alert(me.toLocaleString()); // ERROR: same as toString in IE

jClass

• Concept: basically the same one used by base2


• Troubles: even worse than base2 since there are no explicit searches for toString and valueOf (most common hidden methods)

var ResigClass = jClass.extend({
    init:function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var ResigSub = ResigClass.extend({
    init:function(name, age){
        this._super(name);
        this.age = age;
    },
    toString:function(){
        return this._super() + ": " + this.age;
    }
});
var me = new ResigSub("Andrea", 30);
alert(me);                   // Error: [object Object] in IE
alert(me.toLocaleString());  // Error: [object Object] in IE

MooTools

• Concept: runtime injected parent, similar to base2. In my opinion the most clean and elegant way to extend a class.


• Troubles: Classes are created via Class constructor so we have same bottleneck spotted in base2. Inheritance problems are basically the same found in base2: some hidden method is not inherited.

var MooToolsClass = new Class({
    initialize: function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var MooToolsSub = new Class({
    Extends:MooToolsClass,
    initialize:function(name, age){
        this.parent(name);
        this.age = age;
    },
    toString:function($super){
        return this.parent() + ": " + this.age;
    }
});
var me = new MooToolsSub("Andrea", 30);
alert(me);                  // Andrea: 30 - not inherited in IE
alert(me.toLocaleString()); // ERROR: locale: Andrea in IE

Prototype

• Concept: $super variable as parent sent as first argument, imho the most obtrusive way so far and not elegant/intuitive at all.


• Troubles: something works as expected, but only toString and valueOf, as is for base2, are considered hidden methods. The extra argument and the method overload make this library almost slow as dojo inheritance implementation is.

var ProtoClass = Class.create({
    initialize:function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var ProtoSub = Class.create(ProtoClass, {
    initialize:function($super, name, age){
        $super(name);
        this.age = age;
    },
    toString:function($super){
        return $super() + ": " + this.age;
    }
});
var me = new ProtoSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // ERROR: same as toString in IE

YUI

• Concept: a constructor link to its parent prototype via "this.constructor.superclass". No runtime operations, no injected overloads, just "raw methods" based on explicit calls.


• Troubles: not really. The YUI approach is extremely simple and efficient then "of course it works"!. There are just a couple of steps resolved via YAHOO.lang.extend: the correct constructor reassignment after the prototype one, plus the superclass link. I have just a comment about YUI implementation: guys, why do not you avoid that function creation for each extend call?

    // No var F = function(){}, i SUGGESTION
    extend: function(F){
        return function(subc, superc, overrides) {
            if (!superc||!subc) {
                throw new Error("extend failed, please check that " +
                                "all dependencies are included.");
            }
            F.prototype=superc.prototype;
            subc.prototype=new F;
            subc.prototype.constructor=subc;
            subc.superclass=superc.prototype;
            if (superc.prototype.constructor == OP.constructor) {
                superc.prototype.constructor=superc;
            }
        
            if (overrides) {
                for (var i in overrides) {
                    if (L.hasOwnProperty(overrides, i)) {
                        subc.prototype[i]=overrides[i];
                    }
                }

                L._IEEnumFix(subc.prototype, overrides);
            }
            
        }
    }(function(){}),

And here we are with the scenario:

function YUIClass(name){
    this.name = name;
};
YUIClass.prototype.toString = function(){
    return this.name;
};
YUIClass.prototype.toLocaleString = function(){
    return "locale: " + this.toString();
};
function YUISub(name, age){
    this.constructor.superclass.constructor.call(this, name);
    this.age = age;
};
YAHOO.lang.extend(YUISub, YUIClass); 
YUISub.prototype.toString = function(){
    return this.constructor.superclass.toString.call(this) + ": " + this.age;
};
var me = new YUISub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // locale: Andrea: 30

WebReflection Proposal

After an analysis like this one, how could I skip my "all the best from others without troubles" proposal?
These are my considerations:

• The fastest way to use a parent method is an explicit call


• The best way to perform above step is via a link able to remove explicit dependencies (read: MyParentClassName instead of this.constructor.superclass). In this way methods could be easily transported from a prototype to another one without problems (less memory usage and less code to maintain)


• The this.parent() solution is the cleanest one and generally speaking more close to our concept of "Object Oriented JavaScript". It is portable, it is meaningful, it is shorter than an explicit call with or without a link but it is not that fast to execute.


• Using best practices to cache all we need, create a quick wrapper, resolving hidden methods problems, will not bring us to native or YUI performances, but at least in a good scenario: fast enough to guarantee performances over code elegance and readability

So here we are with my proposal:

• Concept: parent in prototype but changed runtime for hierarchy purpose only if necessary (read: only for overrides). This will allows us to call parent directly in the constructor, as example, so we won't have double calls for each instance. At the same time, this implementation lets us call explicitly a parent method from those whose were not inherited.


• Troubles: performances are the best but still far from native one.

function WRClass(name){
    this.name = name;
};
WRClass.prototype.toString = function(){
    return this.name;
};
WRClass.prototype.toLocaleString = function(){
    return "locale: " + this.toString();
};
function WRSub(name, age){
    this.parent(name);
    this.age = age;
};
wr.extend(WRSub, WRClass, {
    toString:function(){
        return this.parent() + ": " + this.age;
    }
});
var me = new WRSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // locale: Andrea: 30

// last, but not least
WRSub.prototype.explicitParentToString = function(){
    return this.parent.prototype.toString.call(this);
    // instead of
    return this.constructor.superclass.toString.call(this);
};
alert(me.explicitParentToString()); // Andrea

WebReflection proposed Extend

For future improvements/bugs fixes, please use this link.

var wr = {
    extend:function(parent, extend){
        /**
         * (C) Andrea Giamamrchi
         * Mit Style License
         */
        return function(self, Function, Object){
            var prototype = function(){
                this.prototype[key] = 
                    this.prototype.parent && typeof Object[key] == "function" && typeof this.prototype[key] == "function" ?
                        extend(Function, this.prototype[key], Object[key]) :
                        Object[key]
                ;
            };
            if(Object){
                parent.prototype = Function.prototype;
                self.prototype = new parent;
                self.prototype.constructor = self;
                self.prototype.parent = Function.prototype.parent ?
                    extend(Function, Function.prototype.parent, Function) : Function
            } else
                Object = Function;
            for(var key in Object)
                prototype.call(self);
            for(key in {toString:key})
                return self;
            //* ... for Internet Explorer only ...
            for(var
                split = "hasOwnProperty.isPrototypeOf.propertyIsEnumerable.toLocaleString.toString.valueOf".split(".");
                key = split.shift();
            )
                if(Object.hasOwnProperty(key))
                    prototype.call(self);
            //*/
            return self
        }
    }(
        function(){},
        function(parent, extend, Function){
            return function(){
                this.parent = extend;
                var result = Function.apply(this, arguments);
                this.parent = parent;
                return result
            }
        }
    )
};

The Benchmark

I had to choose Prototype or MooTools, since these frameworks seem to have some problem to coexist. Since Prototype has been tested in the Ajaxian post, I decided to put MooTools in the middle.
Something to consider before you try the benchmark page ... I removed the purposeless direct method call since it is absolutely the same for every basic class, created via library or not.
The order is by performances, where generally speaking are these:

1. Ad Hoc Manual Explicit Inheritance


2. YUI lang.extend (close to Ad Hoc)


3. wr.extend - WebReflection proposal (closer to jClass than YUI)


4. jClass (truly close to base2)


5. base2 (truly close to jClass)


6. dojo


7. Prototype


8. MooTools

Try out The Benchmark

And have a nice week end ;-)

Big Douglas begetObject revisited recycling a unique function

With the precedent post I realized I wrote a really tricky way to extend inline a function.Next code is the snippet summary:

MyExtendedConstructor.prototype = function(Function){
    var callee = arguments.callee;
    if(!(this instanceof callee)){
        callee.prototype = Function.prototype;
        return new callee;
    }
}(MyBaseConstructor);

Above code uses the closure itself to create the intermediate constructor.
The reason i chose this way to operate that task was: why should I use another function when I already have one that is the closure itself?

Well done, one function instead of two ... but wait a second, why should I create a different function everytime instead of recycle a single one?

Douglas Crockford begetObject concept

In one of His historical posts, Big Douglas describes simple JavaScript inheritance and object cloning using an intermediate constructor. This is the Object.create function:

Object.create = function (o) {
    function F() {}
    F.prototype = o;
    return new F();
};

Above snippets is still used in I do not know how many JavaScript libraries or code over the net, to extends constructor prototypes or to create a clone of a generic object.

The snippet is clever, powerful, "perfect" for its purpose, but it creates many functions for each object and your JS engine, as your RAM, has not shields to prevent its aggressiveness when you use thousands of times that snippet.

This is a benchmark function example:

function bench(create){
    for(var original = {test:"test"}, o = create(original), i = 0, time = new Date; i < 500000; i++)
        o = create(o);
    return new Date - time;
};

If we test above function with Douglas Object.create one, the result will be something like:

FireFox 3.0.3 - Intel Core2 6600 @ 2.40 - 2GB DDR2 RAM
------------------------------------------------------
Memory:       121.676 Kb
CPU:          50% (not responding)
Elapsed time: 1769 ms

Object.create revisited version

Next snippet is my revisited version of that function:

Object.create = function(Function){
// WebReflection Revision
return function(Object){
    Function.prototype = Object;
    return new Function;
}}(function(){});

these are advantages about recycling the function:

• memory should not be increased, the function is one


• execution speed should be faster, no functions created for each call


• apparently, not a single behaviour different from the good old snippet

While these are results with the same configuration:

FireFox 3.0.3 - Intel Core2 6600 @ 2.40 - 2GB DDR2 RAM
------------------------------------------------------
Memory:       37.332 Kb
CPU:          35% (responding)
Elapsed time: 855 ms

Seems to be quite impressive, isn't it? Results are tremendously different with Internet Explorer, where the good old way lets the browser ask if it is the case to stop the script: thousands of milliseconds against approximately 1200 with my revision.

Not only to clone

I tested my revision to extend constructors as well, and everything seems to be absolutely fine. This is the function, based on the precedent one:

Function.extend = function(A, B){
    A.prototype = Object.create(B.prototype);
    A.prototype.constructor = A;
};

// Usage Example
Function.extend(MyExtendedConstructor, MyConstructor);

Why does it work?

Everything is about the clone strategy itself. When we clone an object, it does not matter that the original one is modified, the cloned will be an object a part.
Since the constructor used to create the clone is private, and since it is never modified by the function itself, it does not matter how many times we reassign its prototype, since the only important thing is when we create an instance with new keyword. That instance wont loose its inherited methods or properties.
As example:

function A(){};
A.prototype = {sayHello:function(){alert("Hello")}};
var a = new A;

// prototype redefinition
A.prototype = {};

alert(a instanceof A); // FALSE
a.sayHello();          // Hello

As I said, when variable a is created, it inherits everything from A.prototype and, of course, if A.prototype inherits from another constructor, the chain is respected and classic inheritance emulated. Using the unique function inside that closure, we are doing something like this:

function A(){}; // generic constructor

function Intermediate(){}; // intermediate function
Intermediate.prototype = {sayHello:function(){alert("Hello")}};

// assign the prototype creating an instance
// the instance does not loose its methods
// inherited during its constructor
A.prototype = new Intermediate;

var a = new A;

// we are changing the constructor prototype
// but A.prototype is an instance of the precedent one
Intermediate.prototype = {};

// the method is still there
a.sayHello();

// the prototype has not been changed
// when created it inherited precedent
// methods or variables
var b = new A;
b.sayHello();

Conclusion

In my opinion there aren't side effect but only performances and memory consumption improvements for every browser.
I do not know why I did not think about this way to recycle that function before, but for sure I will never use a new intermediate constructor again, unless somebody will post valid reasons to do it.
Finally, if everybody knew about this tricky way to recycle the constructor, I am sorry, I am late.

a new Relator object plus unshared private variables

This is a Robert Nyman's post dedicated reply, about JavaScript inheritance and alternatives and private variables.

First of all, I would like to say thanks to Robert for both interesting articles He is writing about JS inheritance, and a link to a personal comment which aim was to bring there my "old" documentation about classical JavaScript inheritance and usage of prototype, closures, and public, privileged, or private, scope when we create a constructor.

About

Last Rob's post talk about private variables, describing them as shared, if present outside the constructor, and valid only for singleton instances.
This is true, and could cause a lot of headache if we are not truly understanding closures and prototype shared methods behaviour, but there is a way to use this peculiarity about shared private variables to create dedicated private variables.

Before I will write about it, let's look into a generic shared private variable example:

Click = function(){
    // closure for private methods / variables
    
    // private shared variable
    var _total = 0;

    // returned constructor + prototype
    function Click(){};
    Click.prototype.add = function(){
        _total++;
    };
    Click.prototype.getTotal = function(){
        return _total;
    };
    return Click
}();

var left  = new Click,
    right = new Click;

left.add();
alert(right.getTotal()); // 1

Above example shows that if a variable is created outside the constructor and prototype shared methods use that variable, every call to one of those method from a generic instance will modify that single private variable, created once inside that closure. To obtain a private variable we need privileged methods:

Click = function(){ // privileged methods
    var _total = 0;
    this.add = function(){
        _total++;
    };
    this.getTotal = function(){
        return _total;
    };
};

var left  = new Click,
    right = new Click;

left.add();
alert(right.getTotal()); // 0

As discussed before in my doc, in robert's posts, and everywhere else in the web, privileged methods create many functions for each instance, and with big projects this is not good for both memory and CPU usage.

new Relator object and unshared private variables

The Relator is an object capable to relate a generic variable with a clear object, without modifying the original variable.
The classic example is this:

var myNum = 123;
Relator.set(myNum).description = "I am number 123";
alert(myNum.description);              // undefined
alert(Relator.get(myNum).description); // "I am number 123"

Since with Relator it is possible to create a unique relation between a generic object and a private Object, it was natural for me to think that a private variable could be a Relator like object using this as unique relationship.
The new version of my Relator still respect the precedent API, being a Relator itself, but is now able to return a new object Relator like that could be used, as example, inside a closure.

// new Relator can create a Relator like object with method "$"
PrivateRelator = function(Relator){
    // Relator argument is a new Relator like object
    // present only in this scope
    return {
        get:function(what){
            var value   = Relator.get(what);
            return value && value.value;
        },
        set:function(what, value){
            Relator.set(what).value = value;
        }
    }
}(Relator.$()); // create a new Relator

Relator.set(window).value = "Hello World";
Relator.get(window).value; // Hello world
PrivateRelator.get(window); // undefined
PrivateRelator.set(window, "Hello Private World");
PrivateRelator.get(window); // Hello Private World
Relator.get(window).value; // Hello World

The good part of Relator is that the stored variable, if it is an object, is stored by reference, and we can assign more than a private unique relationship between a single object and our extra informations.
The same pattern could be easily re-adapted to create a shared private variables:

Person = function(){
    
    // private methods
    function _getName(){
        return  _private.get(this).name
    };
    function _setName(name){
        _private.get(this).name = name;
    };
    
    // private variable, shared by every function in this scope
    var _private = Relator.$();
    
    // constructor + prototype
    function Person(){
        // bridge to _private shared variable
        _private.set(this);
    };
    Person.prototype.getName = function(){
        return  _getName.call(this);
    };
    Person.prototype.setName = function(name){
        _setName.call(this, name);
    };
    return  Person;

}();

// extended constructor
function Enhanced(){
    // necessary to save
    // this instance into _private variable
    // accessible only via Person scope
    Person.call(this);
};
(function(){ // quick runtime extend
    var callee = arguments.callee;
    if(this instanceof callee)return;
    callee.prototype = Person.prototype;
    Enhanced.prototype = new callee;
})();


var me  = new Person(),
    rob = new Enhanced();

me.setName("Andrea");
rob.setName("Robert");

alert([me.getName(), rob.getName()]);
// Andrea,Robert

Conclusion

Sometime a limitation could be easily managed to obtain desired result.
In this case, thanks to JavaScript closures and its prototype nature, the shared variable become a sort of bridge to obtain private variables for each instance.
It is important to understand that even if we extend the base constructor, every new instance will still persist into original _private variable, inside the Person scope, unless we do not specify a different one, redefining every method that use that variable as well:

(function(_private){
    Enhanced = function(){
        _private.set(this);
    };
    (function(){ // quick runtime extend
        var callee = arguments.callee;
        if(this instanceof callee)return;
        callee.prototype = Person.prototype;
        Enhanced.prototype = new callee;
    })();
    Enhanced.prototype.getName = function(){
        return  _private.get(this).name
    };
    Enhanced.prototype.setName = function(name){
        _private.get(this).name = name;
    };
})(Relator.$());

See you soon ;)

My 5 cents about JavaScript Prototypal Inheritance

Few days ago I read an interesting post about Simple JavaScript Inheritance.
The most hilarious thing is that prototypal inheritance is truly simple, as John wrote, but there are still a lot of developers that do not probably understand perfectly them.

In this link you can find an "all in one" page about JavaScript prototypal inheritcance and classical emulation.

As I wrote at the end of that page, please do not hesitate to correct me if there is something wrong, or please ask me more details if there is something that is not so clear.

Sorry for my not perfect yet English, and have fun with JavaScript.

(happy easter too!)