Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://webreflection.blogspot.com/2009/02/on-javascript-inheritance-performance_28.html below:

Web Reflection: On JavaScript Inheritance Performance

Few days ago I wrote

, 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).

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.

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)
});

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

where my clean and simple implementation bites every other library, even the classical full namespace way.

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

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.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4