直接访问原型的值,即 Object.prototype.toString.call()
Value of directly accessing prototype i.e. Object.prototype.toString.call()
是否有理由直接从原型引用方法而不是通过继承?这些似乎是事实上的标准:
var argsArr = Array.prototype.slice.call(arguments);
和
var isArr = Object.prototype.toString.call(object) === '[object Array]';
字面对我来说似乎更好?它更短,阅读起来不那么混乱。
var argsArr = [].slice.call(arguments);
和
var isArr = {}.toString.call(object) === '[object Array]';
如果有性能提升,它必须可以忽略不计,并且函数很容易缓存。也许创建新对象时开销很小,但这又可以忽略不计?
当然,你的方式会很好用。它确实会不必要地创建和丢弃对象,但正如您所说,其开销将非常微不足道。FWIW,可读性的事情是主观的(我发现使用原型的版本更容易阅读。
我认为这主要只是为了避免不必要的创作,不必要的记忆流失。引擎过去比现在慢得多。
采用过早微优化模式...
看起来对于slice
用例,在 Chrome 上使用文字在我的机器上慢了大约 4%,在 Firefox 上它更慢 9%,在 IE10 上完全没有区别。很可能你在那之后做什么都会淹没这种效果。当然,记忆流失的影响更难衡量。
如果您经常这样做,我会绕过整个问题并拥有一个Utils
对象(或将这些对象添加到Array
):
var Utils = (function() {
var arraySlice = Array.prototype.slice; // Or [].slice
var objToString = Object.prototype.toString; // Or {}.toString
function cloneArray(a) {
return arraySlice.call(a);
}
function isArray(a) {
return objToString.call(a) === '[object Array]';
}
return {
cloneArray: cloneArray,
isArray: isArray
};
})();
相关文章:
- Object.prototype using 'this'
- ExtJS 4 Object.prototype fail
- Object.prototype.hasOwnProperty.call() vs Object.prototype.h
- 为什么使用 Object.prototype.hasOwnProperty.call(myObj, prop) 而不是
- childObj.prototype = Object.create(parentObj.prototype) 和 ch
- 如何添加 Object.prototype.x?设置为 enumerable:false
- Object.create() instead of prototype
- 为什么 Object.prototype 和 Object.getOwnPropertyNames(Object.pro
- 引用 Object.prototype.toString.call 导致“TypeError: undefined 不是
- 为什么MDN Object.create polyfill上的Temp.prototype设置为null
- Function.prototype.propertyname === Object.propertyname is t
- Object.seal(Object.prototype)是否使所有对象不可变?
- Object.create Prototype Chains
- Object.Prototype 方法和 IIFE(立即调用的函数表达式)中的“use strict”
- Object.prototype.values 会破坏应用程序
- object.key = fn() 与 object.prototype.key = fn() 之间的差异
- Javascript Prototype Object Constructor
- 从prototype.object获取类上下文
- Rectangle.prototype=Object.create(Shape.prototype)和Rectangle
- 如何绑定'这'prototype.object上的上下文正确