标签:des style blog http color io os ar java
JavaScript has two different ways of comparing the values of objects for equality.
The equality operator consists of two equal signs: ==
JavaScript features weak typing. This means that the equality operator coerces types in order to compare them.
"" == "0" // false 0 == "" // true 0 == "0" // true false == "false" // false false == "0" // true false == undefined // false false == null // false null == undefined // true " \t\r\n" == 0 // true
The above table shows the results of the type coercion, and it is the main reason why the use of ==
is widely regarded as bad practice. It introduces hard-to-track-down bugs due to its complicated conversion rules.
Additionally, there is also a performance impact when type coercion is in play; for example, a string has to be converted to a number before it can be compared to another number.
The strict equality operator consists of three equal signs: ===
.
It works like the normal equality operator, except that strict equality operator does not perform type coercion between its operands.
"" === "0" // false 0 === "" // false 0 === "0" // false false === "false" // false false === "0" // false false === undefined // false false === null // false null === undefined // false " \t\r\n" === 0 // false
The above results are a lot clearer and allow for early breakage of code. This hardens code to a certain degree and also gives performance improvements in case the operands are of different types.
While both ==
and ===
are called equality operators, they behave differently when at least one of their operands is an Object
.
{} === {}; // false new String(‘foo‘) === ‘foo‘; // false new Number(10) === 10; // false var foo = {}; foo === foo; // true
Here, both operators compare for identity and not equality; that is, they will compare for the same instance of the object, much like is
in Python and pointer comparison in C.
It is highly recommended to only use the strict equality operator. In cases where types need to be coerced, it should be done explicitly and not left to the language‘s complicated coercion rules.
typeof
OperatorThe typeof
operator (together with instanceof
) is probably the biggest design flaw of JavaScript, as it is almost completely broken.
Although instanceof
still has limited uses, typeof
really has only one practical use case, which does not happen to be checking the type of an object.
Note: While typeof
can also be called with a function like syntax, i.e. typeof(obj)
, this is not a function call. The parentheses behave as normal and the return value will be used as the operand of the typeof
operator. There is no typeof
function.
Value Class Type ------------------------------------- "foo" String string new String("foo") String object 1.2 Number number new Number(1.2) Number object true Boolean boolean new Boolean(true) Boolean object new Date() Date object new Error() Error object [1,2,3] Array object new Array(1, 2, 3) Array object new Function("") Function function /abc/g RegExp object (function in Nitro/V8) new RegExp("meow") RegExp object (function in Nitro/V8) {} Object object new Object() Object object
In the above table, Type refers to the value that the typeof
operator returns. As can be clearly seen, this value is anything but consistent.
The Class refers to the value of the internal [[Class]]
property of an object.
From the Specification: The value of [[Class]]
can be one of the following strings.Arguments
, Array
, Boolean
,Date
, Error
, Function
,JSON
, Math
, Number
,Object
, RegExp
, String
.
In order to retrieve the value of [[Class]]
, one has to make use of the toString
method of Object.prototype
.
The specification gives exactly one way of accessing the [[Class]]
value, with the use of Object.prototype.toString
.
function is(type, obj) { var clas = Object.prototype.toString.call(obj).slice(8, -1); return obj !== undefined && obj !== null && clas === type; } is(‘String‘, ‘test‘); // true is(‘String‘, new String(‘test‘)); // true
ES5 Note: For convenience the return value of Object.prototype.toString
for both null
and undefined
was changed from Object
to Null
and Undefined
in ECMAScript 5.
In the above example, Object.prototype.toString
gets called with the value of this being set to the object whose [[Class]]
value should be retrieved.
typeof foo !== ‘undefined‘
The above will check whether foo
was actually declared or not; just referencing it would result in a ReferenceError
. This is the only thingtypeof
is actually useful for.
In order to check the type of an object, it is highly recommended to use Object.prototype.toString
because this is the only reliable way of doing so. As shown in the above type table, some return values of typeof
are not defined in the specification; thus, they can differ between implementations.
Unless checking whether a variable is defined, typeof
should be avoided.
instanceof
OperatorThe instanceof
operator compares the constructors of its two operands. It is only useful when comparing custom made objects. Used on built-in types, it is nearly as useless as the typeof operator.
function Foo() {} function Bar() {} Bar.prototype = new Foo(); new Bar() instanceof Bar; // true new Bar() instanceof Foo; // true // This just sets Bar.prototype to the function object Foo, // but not to an actual instance of Foo Bar.prototype = Foo; new Bar() instanceof Foo; // false
instanceof
with Native Typesnew String(‘foo‘) instanceof String; // true new String(‘foo‘) instanceof Object; // true ‘foo‘ instanceof String; // false ‘foo‘ instanceof Object; // false
One important thing to note here is that instanceof
does not work on objects that originate from different JavaScript contexts (e.g. different documents in a web browser), since their constructors will not be the exact same object.
The instanceof
operator should only be used when dealing with custom made objects that originate from the same JavaScript context. Just like the typeof
operator, every other use of it should be avoided.
JavaScript is a weakly typed language, so it will apply type coercion wherever possible.
// These are true new Number(10) == 10; // Number.toString() is converted // back to a number 10 == ‘10‘; // Strings gets converted to Number 10 == ‘+10 ‘; // More string madness 10 == ‘010‘; // And more isNaN(null) == false; // null converts to 0 // which of course is not NaN // These are false 10 == 010; 10 == ‘-10‘;
ES5 Note: Number literals that start with a 0
are interpreted as octal (Base 8). Octal support for these has been removed in ECMAScript 5 strict mode.
To avoid the issues above, use of the strict equal operator is highly recommended. Although this avoids a lot of common pitfalls, there are still many further issues that arise from JavaScript‘s weak typing system.
The constructors of the built in types like Number
and String
behave differently when being used with the new
keyword and without it.
new Number(10) === 10; // False, Object and Number Number(10) === 10; // True, Number and Number new Number(10) + 0 === 10; // True, due to implicit conversion
Using a built-in type like Number
as a constructor will create a new Number
object, but leaving out the new
keyword will make the Number
function behave like a converter.
In addition, passing literals or non-object values will result in even more type coercion.
The best option is to cast to one of the three possible types explicitly.
‘‘ + 10 === ‘10‘; // true
By prepending an empty string, a value can easily be cast to a string.
+‘10‘ === 10; // true
Using the unary plus operator, it is possible to cast to a number.
By using the not operator twice, a value can be converted a boolean.
!!‘foo‘; // true !!‘‘; // false !!‘0‘; // true !!‘1‘; // true !!‘-1‘ // true !!{}; // true !!true; // true
标签:des style blog http color io os ar java
原文地址:http://www.cnblogs.com/ghgyj/p/4006600.html