0

I have seen many explanations of identity equal operator ===, but seems they are not quite accurate as what we understand of identity equality in other languages such as Java.

Seems for base types (such as number, string), === return true indicates if two variables are with the same type and value. But not necessarily the same identity (references to the same object). But for array and map, it does. Here are some examples that cause confusion for me:

s1 = 'a' + '1'
    s2 = 'a' + '1'
    s1 === s2  // true, even they actually reference two different 
objects in memory which suppose to be different identities. 
    
    
    a1 = [1,2]
    a2 = [1,2]
    a1 === a2  // false, as they reference two different objects in memory, even their values are the same.

Could somebody confirm my understanding is right? Also is there a real identity equality check for strings in Javascript. i.e. s1 === s2 should return false in the above example?

10 Rep
  • 2,217
  • 7
  • 19
  • 33
Jianwu Chen
  • 5,336
  • 3
  • 30
  • 35
  • 1
    "true, even they actually reference two different objects in memory which suppose to be different identities" - what makes you so sure there are two different objects in memory? (Strings aren't even objects in Javascript, but even ignoring that, why do you think there are two copies in memory?) – user2357112 Jul 09 '20 at 02:41
  • You are not comparing objects, you are comparing a string. A basic type. Thats like asking to compare primitive variables in C++ or C#. If you want to compare objects. Create an object that contains the members you want. – John Jul 09 '20 at 02:41
  • Strings don't have identities in Javascript. Giving them identities would be completely useless, serving only to inhibit optimizations and invite bugs. – user2357112 Jul 09 '20 at 02:43

2 Answers2

1

Thanks for the answers. I think the source of the truth is the Javascript language spec regarding Strict Equality Comparison. It clearly specifies the behavior in SameValueNonNumber(x, y). The confusion is many articles misused the term Identity Equality instead of Strict Equality, there's no such concept of Identity Equality based on the spec. (Although it's similar behavior for Object types as specified in item 8 in the SameValueNonNumber(x, y)). So I believe the answer is not possible to do a string identity equality check in Javascript.

Jianwu Chen
  • 5,336
  • 3
  • 30
  • 35
0

This is because a string is a primitive type where an array is an object type. Primitives can be compared as you'd expect however when comparing objects, you're comparing the references and not the objects themselves.

s1 = new String('a1');
s2 = new String('a1');
s1 === s2 // false

Equality comparisons and sameness over on MDN

If you are uncertain about what you are dealing with (a primitive like number or string, or an object), typeof is there to figure out

typeof new String() // object
typeof '' // string
Artur
  • 334
  • 5
  • 15
  • 1
    There are no “references” in ECMAScript. It is confusing to use out of place terminology. The standard explains the behavior of === *without* using such terms borrowed from elsewhere. See https://www.ecma-international.org/ecma-262/10.0/index.html#sec-strict-equality-comparison – user2864740 Jul 09 '20 at 02:55
  • @user2864740 There is a definite distinction between primitive and reference types in JavaScript. – Bren Jul 09 '20 at 02:56
  • No. There is a difference between Primitve and Objects in ECMAScript: there are **no reference types** defined in the standard. (The Reference Type Specification is a different concept entirely.) – user2864740 Jul 09 '20 at 02:58
  • 1
    There are definitely "references" in js. That is why we can have a `Reference Error`. This might be more a question of terminology @user2864740, but I do not know how else to call a reference... – Artur Jul 09 '20 at 02:58
  • An Object is itself. Expressions can evaluate to objects.. note that **the Reference Error does not refer to “reference types”.** This is different from Java or C# “null reference / pointer” errors which *do*. Using the wrong term adds to such incorrect misconceptions. – user2864740 Jul 09 '20 at 02:59
  • 1
    If you assign an object to a variable, the object is located in memory, and the variable is simply a pointer to where the object is located, aka a reference. – Bren Jul 09 '20 at 03:00
  • `Object`, is not incorrect, but I find that terminology more confusing. If you try explaining why an variable containing an object is equal to another, you will explain it as "it is the reference pointing to the same object", not "it is the same object" – Artur Jul 09 '20 at 03:01
  • I’ve linked the reference (note: correctly used term) above. Try reading it sometime instead of drawing in explanations or justifications involving implementation details. – user2864740 Jul 09 '20 at 03:01
  • As I said before checking out the link you provided, `Object` (or as the link says `Object value`), is valid but confusing for people coming from other languages (or those not sinking in the term pool). Under the hood, we will still be talking about `references`, because addressing is the base of computer architecture. Once again, this is a question of terminology, which can be very much subjective and loose from language to language. – Artur Jul 09 '20 at 03:08