Benefits Of Saving Reference To Built-in Methods

ap = Array.prototype, aps = ap.slice, apsp = ap.splice, I often see code like above in different frameworks. What are the benefits of this? Why not use it directly?

Solution 1:

When used exactly as you've shown, the primary reason is to reduce the amount of typing in code that will heavily utilize the referenced method or object. Further, this can have the effect of reducing the overall size of a script. Consider:

Array.prototype.someFunction1 = function () { /*someFunction1 */ };
Array.prototype.someFunction2 = function () { /*someFunction2 */ };
Array.prototype.someFunction3 = function () { /*someFunction3 */ };
Array.prototype.someFunction4 = function () { /*someFunction4 */ };

... (284 characters) versus:

var ap = Array.prototype;
ap.someFunction1 = function () { /*someFunction1 */ };
ap.someFunction2 = function () { /*someFunction2 */ };
ap.someFunction3 = function () { /*someFunction3 */ };
ap.someFunction4 = function () { /*someFunction4 */ };

... which has 261 characters. Trivial, yes, but on a large scale this can make enough of a difference to be worthwhile in distributed code (think Google-hosted jQuery).

Sometimes, however, this is done to preserve scope through a closure:

var self = this;
  this.someProperty = 5;
  var myDiv = document.createElement('div');
  myDiv.addEventListener('mousedown', function(e) { alert(self.someProperty); }, false);

Solution 2:

Several benefits:

1. Faster at run-time (fewer lookups to get the final result)
2. Smaller code before minification
3. Easier to reduce even more with minification
4. Less typing when coding

One should note that I think it makes the code less readable to people not already familiar with the code or its conventions because the code isn't as self documenting. Everyone knows what Array.prototype.splice is but strangers don't know what aps is until they study the code, track down its definition and remember what it is.

---

I was asked in a comment to explain the fewer lookups issue:

For the interpreter to resolve Array.prototype.splice, it has to do the following:

1. Look in the local scope for the Array name. It doesn't find it.
2. Look in any closures (e.g. parent scope) for the Array name. It doesn't find it.
3. Look in the global scope for the Array name. It finds it.
4. On the Array object, look for the prototype property.
5. On the prototype property, look for the splice property and now it finally has the function it needs.

For the interpreter to resolve aps, it has to do this:

1. Look in the local scope for the aps name. It finds it and not it has the function it needs.

The pre-assignment to aps has essentially pre-done the lookups so that they are already resolved at runtime. This removes some flexibility because if the value of the splice or prototype properties are changed, the variable aps won't reflect that change, but if you know they aren't supposed to change (something the run-time interpreter doesn't know), then you can take advantage of this shortcut.

Solution 3:

One functional reason this pattern would exist would be to protect against other javascript code changing the meaning of the particular methods. Essentially protecting from code like the following

Array.prototype.splice = function() {
  // This is evil
};

The other more likely though is the developer simply didn't want to type Array.prototype.splice and prefered a shorter version like apsp.

Solution 4:

There are two benefits.

• a is easier to minify then Array.prototype.slice
• a is a single lookup where Array.prototype.slice is multiple look ups

So basically they are both micro optimisations. Which are valuable in libraries because libraries care about being as efficient as possible