Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #37257 > unrolled thread

Object equals other object

Back to article view | Back to comp.lang.javascript

Contents

  Object equals other object Andrew Poulos <ap_prog@hotmail.com> - 2019-09-16 12:44 +1000
    Re: Object equals other object "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-09-16 09:00 +0200
      Re: Object equals other object Andrew Poulos <ap_prog@hotmail.com> - 2019-09-16 18:30 +1000
        Re: Object equals other object Julio Di Egidio <julio@diegidio.name> - 2019-09-16 02:01 -0700
          Re: Object equals other object Andrew Poulos <ap_prog@hotmail.com> - 2019-09-16 19:39 +1000
          Re: Object equals other object John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-16 18:29 +0100
        Re: Object equals other object John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-16 10:04 +0100
          Re: Object equals other object Julio Di Egidio <julio@diegidio.name> - 2019-09-16 02:21 -0700
            Re: Object equals other object John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-16 18:39 +0100
            Re: Object equals other object Arno Welzel <usenet@arnowelzel.de> - 2019-09-17 10:45 +0200
        Re: Object equals other object Arno Welzel <usenet@arnowelzel.de> - 2019-09-16 11:49 +0200
          Re: Object equals other object Julio Di Egidio <julio@diegidio.name> - 2019-09-16 02:54 -0700
            Re: Object equals other object Arno Welzel <usenet@arnowelzel.de> - 2019-09-16 11:56 +0200
              Re: Object equals other object Julio Di Egidio <julio@diegidio.name> - 2019-09-16 03:09 -0700
                Re: Object equals other object Arno Welzel <usenet@arnowelzel.de> - 2019-09-16 13:47 +0200
                  Re: Object equals other object Jon Ribbens <jon+usenet@unequivocal.eu> - 2019-09-16 13:43 +0000
    Re: Object equals other object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-09-17 00:53 +0200
      Re: Object equals other object Jon Ribbens <jon+usenet@unequivocal.eu> - 2019-09-16 23:03 +0000
        Re: Object equals other object "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-09-17 16:16 +0200
          Re: Object equals other object Arno Welzel <usenet@arnowelzel.de> - 2019-09-17 16:57 +0200
        Re: Object equals other object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-09-17 16:58 +0200
          Re: Object equals other object Jon Ribbens <jon+usenet@unequivocal.eu> - 2019-09-17 16:31 +0000
          Re: Object equals other object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-11-30 04:38 +0100
      Re: Object equals other object John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-17 18:46 +0100

Page 1 of 2  [1] 2  Next page →

#37257 — Object equals other object

If I have

let a = { "c": 1 },
     b = { "c": 1 };

then

console.log(a === b); // false.

My question is, why was it decided that JavaScript is to return false 
even if the two objects have the same number of properties, all the 
properties are named the same, and all the properties values are identical?

Andrew Poulos

[toc] | [next] | [standalone]

#37258

Andrew Poulos <ap_prog@hotmail.com> wrote on 16 Sep 2019 in
comp.lang.javascript: 

> If I have
> 
> let a = { "c": 1 },
>      b = { "c": 1 };
> 
> then
> 
> console.log(a === b); // false.
> 
> My question is, why was it decided that JavaScript is to return false 
> even if the two objects have the same number of properties, all the 
> properties are named the same, and all the properties values are
> identical? 

Two DIFFERENT objects can never "be" the same.


However, the SAME object can be assigned different names:

let a = { 'c': 1 };
let d = a;
console.log(a === d); // true
console.log(a.c, d.c) // 1 1

a.c = 2;
console.log(a === d); // true
console.log(a.c, d.c) // 2 2


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#37259

On 16/09/2019 5:00 pm, Evertjan. wrote:
> Andrew Poulos <ap_prog@hotmail.com> wrote on 16 Sep 2019 in
> comp.lang.javascript:
> 
>> If I have
>>
>> let a = { "c": 1 },
>>       b = { "c": 1 };
>>
>> then
>>
>> console.log(a === b); // false.
>>
>> My question is, why was it decided that JavaScript is to return false
>> even if the two objects have the same number of properties, all the
>> properties are named the same, and all the properties values are
>> identical?
> 
> Two DIFFERENT objects can never "be" the same.

Yes, but why can't two objects that have exactly the same properties and 
corresponding property values be considered the same? If I JSON 
stringify both of them then they magically become the same, so why not 
before?

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#37260

On Monday, 16 September 2019 10:30:38 UTC+2, Andrew Poulos  wrote:
> On 16/09/2019 5:00 pm, Evertjan. wrote:
> > Andrew Poulos <ap_prog@hotmail.com> wrote on 16 Sep 2019 in
> > comp.lang.javascript:
> > 
> >> If I have
> >>
> >> let a = { "c": 1 },
> >>       b = { "c": 1 };
> >>
> >> then
> >>
> >> console.log(a === b); // false.
> >>
> >> My question is, why was it decided that JavaScript is to return false
> >> even if the two objects have the same number of properties, all the
> >> properties are named the same, and all the properties values are
> >> identical?
> > 
> > Two DIFFERENT objects can never "be" the same.
> 
> Yes, but why can't two objects that have exactly the same properties and 
> corresponding property values be considered the same? If I JSON 
> stringify both of them then they magically become the same, so why not 
> before?

Reference equality: objects are compared (and passed around) by reference.
That is common to pretty much all languages with any support for objects.

BTW, JSON.stringify is indeed sometimes used to compare objects, but keep in
mind it is not a reliable method in general (not to mention, it's suboptimal),
because the output is not 100% faithful to the original object.

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#37264

On 16/09/2019 7:01 pm, Julio Di Egidio wrote:
> On Monday, 16 September 2019 10:30:38 UTC+2, Andrew Poulos  wrote:
>> On 16/09/2019 5:00 pm, Evertjan. wrote:
>>> Andrew Poulos <ap_prog@hotmail.com> wrote on 16 Sep 2019 in
>>> comp.lang.javascript:
>>>
>>>> If I have
>>>>
>>>> let a = { "c": 1 },
>>>>        b = { "c": 1 };
>>>>
>>>> then
>>>>
>>>> console.log(a === b); // false.
>>>>
>>>> My question is, why was it decided that JavaScript is to return false
>>>> even if the two objects have the same number of properties, all the
>>>> properties are named the same, and all the properties values are
>>>> identical?
>>>
>>> Two DIFFERENT objects can never "be" the same.
>>
>> Yes, but why can't two objects that have exactly the same properties and
>> corresponding property values be considered the same? If I JSON
>> stringify both of them then they magically become the same, so why not
>> before?
> 
> Reference equality: objects are compared (and passed around) by reference.
> That is common to pretty much all languages with any support for objects.

Ok thanks, I think I can see the issue. For the simple objects I'm 
working with "equality" might make sense but not so for complex ones.

> BTW, JSON.stringify is indeed sometimes used to compare objects, but keep in
> mind it is not a reliable method in general (not to mention, it's suboptimal),
> because the output is not 100% faithful to the original object.

Luckily, the objects I'm comparing are simple.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#37274

On Mon, 16 Sep 2019 02:01:33 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

  <snip
>Reference equality: objects are compared (and passed around) by reference.

Now explain what happens in products that don't allow values to be
references.


>That is common to pretty much all languages with any support for objects.
  <snip>

But not C++.

  John

[toc] | [prev] | [next] | [standalone]

#37261

On Mon, 16 Sep 2019 18:30:26 +1000, Andrew Poulos
<ap_prog@hotmail.com> wrote:

  <snip>
>Yes, but why can't two objects that have exactly the same properties and 
>corresponding property values be considered the same? If I JSON 
>stringify both of them then they magically become the same, so why not 
>before?

Well, you would need another equals operator for that. ==== ?

Ordinary === says that if true and you alter one object then the other
will also be altered. I.e They are the *same* object.

Would your ==== be true if the objects have different prototypes?

  John

[toc] | [prev] | [next] | [standalone]

#37262

On Monday, 16 September 2019 11:05:02 UTC+2, John G Harris  wrote:
> On Mon, 16 Sep 2019 18:30:26 +1000, Andrew Poulos
> <ap_prog@hotmail.com> wrote:
> 
>   <snip>
> >Yes, but why can't two objects that have exactly the same properties and 
> >corresponding property values be considered the same? If I JSON 
> >stringify both of them then they magically become the same, so why not 
> >before?
> 
> Well, you would need another equals operator for that. ==== ?

An overloadable operator as well as an overloadable equatable interface,
that's what you find in the usual object oriented language, but not in JS.

> Ordinary === says that if true and you alter one object then the other
> will also be altered. I.e They are the *same* object.

Not, that's not it, that compares values, which might be primitive values
or object references, so you change the original and the other does NOT
ever change.  --  You are simply confusing things, because you are too inept
to even try and write two lines of code to check your (lack of) knowledge
before writing just nonsense.

More generally, you guys should try and get your head around the fact that JS
is NOT an object-oriented language, not by any sensible stretch: and then many
things become at least clearer.

Julio

[toc] | [prev] | [next] | [standalone]

#37275

On Mon, 16 Sep 2019 02:21:15 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

>On Monday, 16 September 2019 11:05:02 UTC+2, John G Harris  wrote:
>> On Mon, 16 Sep 2019 18:30:26 +1000, Andrew Poulos
>> <ap_prog@hotmail.com> wrote:
>> 
>>   <snip>
>> >Yes, but why can't two objects that have exactly the same properties and 
>> >corresponding property values be considered the same? If I JSON 
>> >stringify both of them then they magically become the same, so why not 
>> >before?
>> 
>> Well, you would need another equals operator for that. ==== ?
>
>An overloadable operator as well as an overloadable equatable interface,
>that's what you find in the usual object oriented language, but not in JS.

Nope. Overloading uses the types of the operands to decide which
function to call. If you want different functions to be used with the
same types, as here, you have to have different names for the
functions.


>> Ordinary === says that if true and you alter one object then the other
>> will also be altered. I.e They are the *same* object.
>
>Not, that's not it, that compares values, which might be primitive values
>or object references, so you change the original and the other does NOT
>ever change.  --  You are simply confusing things, because you are too inept
>to even try and write two lines of code to check your (lack of) knowledge
>before writing just nonsense.

What a pitiful reply. Very obviously I was talking about the
particular case presented by Andrew : comparison of objects.


>More generally, you guys should try and get your head around the fact that JS
>is NOT an object-oriented language, not by any sensible stretch: and then many
>things become at least clearer.

Oh God, not that BS again :-(

  John

[toc] | [prev] | [next] | [standalone]

#37285

On 16.09.19 11:21, Julio Di Egidio wrote:

[...]
> More generally, you guys should try and get your head around the fact that JS
> is NOT an object-oriented language, not by any sensible stretch: and then many
> things become at least clearer.

<https://www.ecma-international.org/ecma-262/10.0/index.html#sec-global-object>

"18 The Global Object"

<https://www.ecma-international.org/ecma-262/10.0/index.html#sec-fundamental-objects>

"19 Fundamental Objects

19.1 Object Objects

19.1.1The Object Constructor

The Object constructor:

    is the intrinsic object %Object%.
    is the initial value of the Object property of the global object.
    creates a new ordinary object when called as a constructor.
    performs a type conversion when called as a function rather than as
a constructor.
    is designed to be subclassable. It may be used as the value of an
extends clause of a class definition."

Hmmm... at least the specification is then quite confusing if the
language is not object oriented.

And even classes exist since ECMAScript 2015:

<https://www.ecma-international.org/ecma-262/10.0/index.html#sec-class-definitions>

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes>

So why should one consider JavaScript *not* object oriented?


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#37265

On 16.09.19 10:30, Andrew Poulos wrote:

> On 16/09/2019 5:00 pm, Evertjan. wrote:
>> Andrew Poulos <ap_prog@hotmail.com> wrote on 16 Sep 2019 in
>> comp.lang.javascript:
>>
>>> If I have
>>>
>>> let a = { "c": 1 },
>>>       b = { "c": 1 };
>>>
>>> then
>>>
>>> console.log(a === b); // false.
>>>
>>> My question is, why was it decided that JavaScript is to return false
>>> even if the two objects have the same number of properties, all the
>>> properties are named the same, and all the properties values are
>>> identical?
>>
>> Two DIFFERENT objects can never "be" the same.
> 
> Yes, but why can't two objects that have exactly the same properties and 
> corresponding property values be considered the same? If I JSON 
> stringify both of them then they magically become the same, so why not 
> before?

Because "===" does not convert object properties to a value for comparison.

"a === b" is only true if a and b are exactly same thing and not just
the same value after some conversion.

If you only want to compare values, use "==".



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#37266

On Monday, 16 September 2019 11:49:52 UTC+2, Arno Welzel  wrote:
> On 16.09.19 10:30, Andrew Poulos wrote:
> 
> > On 16/09/2019 5:00 pm, Evertjan. wrote:
> >> Andrew Poulos <ap_prog@hotmail.com> wrote on 16 Sep 2019 in
> >> comp.lang.javascript:
> >>
> >>> If I have
> >>>
> >>> let a = { "c": 1 },
> >>>       b = { "c": 1 };
> >>>
> >>> then
> >>>
> >>> console.log(a === b); // false.
> >>>
> >>> My question is, why was it decided that JavaScript is to return false
> >>> even if the two objects have the same number of properties, all the
> >>> properties are named the same, and all the properties values are
> >>> identical?
> >>
> >> Two DIFFERENT objects can never "be" the same.
> > 
> > Yes, but why can't two objects that have exactly the same properties and 
> > corresponding property values be considered the same? If I JSON 
> > stringify both of them then they magically become the same, so why not 
> > before?
> 
> Because "===" does not convert object properties to a value for comparison.
> 
> "a === b" is only true if a and b are exactly same thing and not just
> the same value after some conversion.
> 
> If you only want to compare values, use "==".

Just try this: alert({}=={})

Ah, the fucking hubris...

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#37268

On 16.09.19 11:54, Julio Di Egidio wrote:

> On Monday, 16 September 2019 11:49:52 UTC+2, Arno Welzel  wrote:
>> On 16.09.19 10:30, Andrew Poulos wrote:
>>
>>> On 16/09/2019 5:00 pm, Evertjan. wrote:
>>>> Andrew Poulos <ap_prog@hotmail.com> wrote on 16 Sep 2019 in
>>>> comp.lang.javascript:
>>>>
>>>>> If I have
>>>>>
>>>>> let a = { "c": 1 },
>>>>>       b = { "c": 1 };
>>>>>
>>>>> then
>>>>>
>>>>> console.log(a === b); // false.
>>>>>
>>>>> My question is, why was it decided that JavaScript is to return false
>>>>> even if the two objects have the same number of properties, all the
>>>>> properties are named the same, and all the properties values are
>>>>> identical?
>>>>
>>>> Two DIFFERENT objects can never "be" the same.
>>>
>>> Yes, but why can't two objects that have exactly the same properties and 
>>> corresponding property values be considered the same? If I JSON 
>>> stringify both of them then they magically become the same, so why not 
>>> before?
>>
>> Because "===" does not convert object properties to a value for comparison.
>>
>> "a === b" is only true if a and b are exactly same thing and not just
>> the same value after some conversion.
>>
>> If you only want to compare values, use "==".
> 
> Just try this: alert({}=={})

This is not what I talked about.

> Ah, the fucking hubris...

Not helpful as usual.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#37270

On Monday, 16 September 2019 11:56:40 UTC+2, Arno Welzel  wrote:
> On 16.09.19 11:54, Julio Di Egidio wrote:
> > On Monday, 16 September 2019 11:49:52 UTC+2, Arno Welzel  wrote:
> >> On 16.09.19 10:30, Andrew Poulos wrote:
> >>> On 16/09/2019 5:00 pm, Evertjan. wrote:
> >>>> Andrew Poulos <ap_prog@hotmail.com> wrote on 16 Sep 2019 in
> >>>> comp.lang.javascript:
> >>>>
> >>>>> If I have
> >>>>>
> >>>>> let a = { "c": 1 },
> >>>>>       b = { "c": 1 };
> >>>>>
> >>>>> then
> >>>>>
> >>>>> console.log(a === b); // false.
> >>>>>
> >>>>> My question is, why was it decided that JavaScript is to return false
> >>>>> even if the two objects have the same number of properties, all the
> >>>>> properties are named the same, and all the properties values are
> >>>>> identical?
> >>>>
> >>>> Two DIFFERENT objects can never "be" the same.
> >>>
> >>> Yes, but why can't two objects that have exactly the same properties and 
> >>> corresponding property values be considered the same? If I JSON 
> >>> stringify both of them then they magically become the same, so why not 
> >>> before?
> >>
> >> Because "===" does not convert object properties to a value for comparison.
> >>
> >> "a === b" is only true if a and b are exactly same thing and not just
> >> the same value after some conversion.
> >>
> >> If you only want to compare values, use "==".
> > 
> > Just try this: alert({}=={})
> 
> This is not what I talked about.

Then you don't even know what you are talking about.

> > Ah, the fucking hubris...
> 
> Not helpful as usual.

Sure I am helpful, I am now exposing your crap and fraud: and it's just
the beginning, I had been refraining up to this point, I always give people
a chance.

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#37271

On 16.09.19 12:09, Julio Di Egidio wrote:

[...]
> Sure I am helpful, I am now exposing your crap and fraud: and it's just
> the beginning, I had been refraining up to this point, I always give people
> a chance.
> 
> *Plonk*

Why to you "*Plonk*" me and then continue to read my posts? And you
should also see a therapists to deal with your social problems.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#37273

On 2019-09-16, Arno Welzel <usenet@arnowelzel.de> wrote:
> On 16.09.19 12:09, Julio Di Egidio wrote:
> [...]
>> Sure I am helpful, I am now exposing your crap and fraud: and it's just
>> the beginning, I had been refraining up to this point, I always give people
>> a chance.
>> 
>> *Plonk*
>
> Why to you "*Plonk*" me and then continue to read my posts?

I have been assuming that "Plonk" is his middle name and it's part of
his Usenet signature file.

[toc] | [prev] | [next] | [standalone]

#37280

Andrew Poulos wrote:

> If I have
> 
> let a = { "c": 1 },
>      b = { "c": 1 };
> 
> then
> 
> console.log(a === b); // false.
> 
> My question is, why was it decided that JavaScript is to return false
> even if the two objects have the same number of properties, all the
> properties are named the same, and all the properties values are
> identical?

History suggests that Brendan Eich decided to define it so for his language 
because Java works this way.  See also my Bachelor thesis 
(<https://10.13140/RG.2.2.25521.63840>), subsection 2.1 “ECMAScript”, and 
references.

Presumably Java, among other programming languages, defined it so because it 
is easier and more efficient to compare two references to one object each 
than to compare all properties of those objects.  Because then you only have 
to compare two pointer values.

Note that in order for two objects to be equal in all properties, not only 
the properties of the object has to be compared, but also the properties of 
their superclasses (in ECMAScript: objects in their prototype chain), i.e. 
the memory areas where the data of the objects are stored and the memory 
areas where the data of their superclasses are stored.

Java has the equals() method to facilitate the customizable comparison of 
objects based on their properties.  Unlike ECMAScript, this requirement also 
extends to strings:

  "foo" == "foo"

yields `false' in Java, while

  "foo".equals("foo")

yields true.  This is actually useful because it also handled Unicode 
composition.  In ECMAScript we usually get away with `==' because we 
consider only ASCII characters; semantically, "e" + "\u0300" == "è" should 
yield `true' but does not, and to date there is apparently no method defined 
in ECMAScript to do a proper comparison; String.prototype.localeCompare(), 
ECMA-402, §14.1.1 just ignores the accent, it does not actually compare
the composed/decomposed sequences.

<https://stackoverflow.com/a/7520464/855543>
<https://stackoverflow.com/a/56574119/855543>
<https://docs.oracle.com/javase/9/docs/api/java/lang/String.html>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#37281

On 2019-09-16, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> See also my Bachelor thesis (<https://10.13140/RG.2.2.25521.63840>)

I don't think that's right.

[toc] | [prev] | [next] | [standalone]

#37290

Jon Ribbens <jon+usenet@unequivocal.eu> wrote on 17 Sep 2019 in 
comp.lang.javascript:

> On 2019-09-16, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> See also my Bachelor thesis (<https://10.13140/RG.2.2.25521.63840>)
> 
> I don't think that's right.

How can an invitation to see something too not be right?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#37291

On 17.09.19 16:16, Evertjan. wrote:

> Jon Ribbens <jon+usenet@unequivocal.eu> wrote on 17 Sep 2019 in 
> comp.lang.javascript:
> 
>> On 2019-09-16, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>>> See also my Bachelor thesis (<https://10.13140/RG.2.2.25521.63840>)
>>
>> I don't think that's right.
> 
> How can an invitation to see something too not be right?

Probaly Jon Ribbens talks about the URL. There is no Domain "10.13140".


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web