This question already has answers here:
Why "foo".toString() is not the same as toString.call("foo")?
(3 answers)
Closed 7 years ago.
As the title's saying,the below two ways of using toString() are returning different results,I am wondering why , because I thought the 'this' here are the same in these two , both object arr.
var arr = [1,2,3]
toString.call(arr) //"[object Array]"
arr.toString() //"1,2,3"
toString as a "function" is actually window.toString, meaning Object.prototype.toString. On the other hand, arr.toString is Array.prototype.toString. Both methods are specialised to produce different output appropriate for their type.
Related
This question already has answers here:
What is the difference between JavaScript object and primitive types?
(1 answer)
Why to avoid creating objects of primitives in JavaScript?
(4 answers)
JavaScript primitive types and corresponding objects
(2 answers)
Closed 2 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Duplicate This question has been answered, is not unique, and doesn’t differentiate itself from another question.
Are there any good reasons to use new Number(n)? Why does this constructor exist?
I can think of several reasons to avoid it, eg.,
literals are more memory efficient since they don't construct anything new.
literals are equal to each other (5 === 5 but new Number(5) !== new Number(5)).
the typeof operator indicates that it's a number rather than an object.
new Number(0) is never falsey. (!!new Number(false) == true).
You can use it for type conversion, but there are more concise methods. (+false === 0).
To be clear, I understand the Number object has useful methods and properties, my question is specifically about the constructor.
I'm using Number as an example, but I don't understand why Javascript exposes other constructors where literals are available either (String, Object, Array, etc.).
Why do these exist and are there ever any good reason to use them?
This question already has answers here:
What is the motivation for bringing Symbols to ES6?
(7 answers)
Closed 4 years ago.
I Googled a lot about new primitive type "Symbol" but still cannot understand actual use of it. What I understood is:
They are a primitive type, just as integer or string.
They are not a constructor function, hence you cannot use new Symbol() syntax.
But why is it used? String/Integer/Boolean have their uses which are clear, but what's the use of Symbol() exactly?
Moreover, for this code:
var data1 = Symbol();
var data2= Symbol('dummy');
why Symbol('dummy') === Symbol('dummy') is false?
This code Symbol('dummy') === Symbol('dummy') is false because each symbol is strictly unique.
Even if you use the same description (dummy), they are actually two different unique symbols.
They are used as identifiers.
You can read more about them here
This question already has answers here:
What’s the difference between “{}” and “[]” while declaring a JavaScript array?
(8 answers)
Closed 4 years ago.
The point of confusion is - when we check the type of array or object using typeof get the return value as Object. So what's the main difference between them.
You can check using constructor.name
const myArr = []
const myObj = {}
console.log(`myArr is an ${myArr.constructor.name}`)
console.log(`my Obj is an ${myObj.constructor.name}`)
This question already has answers here:
How to compare arrays in JavaScript?
(55 answers)
Closed 7 years ago.
why is that? I assumed it's some implicit type conversion at first, but [] == [] is also false.
Arrays in javascript are Objects. Objects are compared by identity. So no two objects created by different literals (or by other means) are going to be equal (either strictly (===) or loosely (==)).
This question already has answers here:
Why is it Object.defineProperty() rather than this.defineProperty() (for objects)?
(3 answers)
Closed 8 years ago.
Both of these obviously do similar things but my question is why is one on the prototype and one on the Object?
For example, both of these called differently. Is there a logical reason why this is the case?
var o = {name: "value"}
o.hasOwnProperty("name") //true
Object.getOwnPropertyNames(o); //name
//Couldn't the above have been coded so we can run o.getOwnPropertNames();
Thanks.
The problem with adding these methods to the prototype is taht they are prone to getting overloaded.
var o = {};
o.getOwnPropertyNames = 17;
//What now?
In fact, you would often see people doing
Object.prototype.hasOwnProperty.call(o, propname);
in order to avoid the overloading issue with hasOwnProperty.