Discussion on: Data Types in JavaScript

View post

One fact most people miss:

'All types except objects define immutable values (that is, values which can't be changed). For example, Strings are immutable. We refer to values of these types as "primitive values".'

let value = 0;
value = 1;

But didn't value just mutate?

What happened is that the "name" value was rebound to a new value. The 0 wasn't changed, value is simply referring to an entirely different value, in this case 1.

From that perspective

const value = 0; // can't be changed
const obj = {
  value: 0,
}; // can never refer to a different object etc.

obj.value = 1;

const simply means the binding is constant.

In the case of value the binding referred to a primitive data type which is always immutable so nothing can be changed.
In the case of obj the binding refers to one specific object (which obj is permanently bound to). That has no influence on the properties of that object which still can be changed. The same is true for arrays as those are just special objects.

Given that typeof classifies arrays as object hints at the fact that arrays are just objects with a "special power", so Array.isArray() is necessary to identify them as an array.

On the flip side typeof on a function comes back as function. For me personally this shows that the statement "functions are first class objects" is a misguided class-based object-oriented perspective. Functions work as objects for the sake of convenience but they are functions first (which can operate as methods) and objects last. That's why I refer to JavaScript as Function-Oriented.

Note that null was introduced early on to represent "absence of an object" in a planned Java-to-JavaScript bridge. That's why typeof null is object.

The true bottom type of JavaScript is undefined. The rule when to use one or the other are just conventions; one convention is to avoid null at all cost.

Array (collection of data of same data type, it is just like java)

They can be used that way. But is also common to use them as tuples: a tuple has a fixed number of elements but each element position can imply a different data type.

Note that Object.create(null) can create objects without a prototype; so there is no guarantee that Object is in the prototype chain (no-prototype-builtins).

That said the abuse of plain objects as maps is limited as property keys have to be strings or symbols, everything else is coerced via .toString() to a string. In general Map makes more sense especially as key deletion is less disruptive.

One final piece of advice (from personal experience):

Do not approach JavaScript from Java as a point of familiarity

That is a path of pain and unmet expectations.

JavaScript is its own thing - start from scratch. Brendan Eich was hired intending to do "Scheme in the browser" - later (marketing) directives imposed the JavaScript (formerly Mocha, and then LiveScript) name and the Java-like syntax in the hopes of increasing adoption.