Object.isEqual

[Steve Fink]

It would be nice to have *something* for this. Some remaining problems I 
see with using JSON serialization, let's call it JSON.isEqual:
  - JS has order, JSON does not
  - JSON lacks NaN, +/-Infinity (and JSON.stringify maps these to null, 
which means JSON.isEqual({x: 0/0}, {x: 1/0}))
  - cycles
  - ...and everything under your "trivial generalisation"

It still seems like it'd be unfortunate if !JSON.isEqual({foo: val1}, 
{foo: val2}) where val1 === val2 (because val1/2 is not serializable, eg 
it has a cycle).


Also, what is

     var x = 4;
     JSON.isEqual({get foo() { return x++; }}, {foo: 4})

? If you went purely by "whatever JSON.stringify would return", then 
this would be true once and false afterwards.

This may seem like nitpicking, but if you don't nail down the exact 
semantics, then engines will end up doing the JSON serialization and a 
string compare, which rather defeats the purpose. If you stick to 
something simple like comparing JSON.stringify output, then they will 
pretty much *have* to do this, since there are so many observable side 
effects like getter invocation and proxy traps. You *could* define 
semantics that cover a large percentage of the interesting cases, but 
JSON isn't going to be of much help.

And for the record, JSON does not have an intuitive semantics at all. It 
has intuitive semantics for a small subset of values, a subset that is 
rarely adhered to except near interchange points where JSON makes sense. 
(And even then, it's common to accidentally step outside of it, for 
example by having something overflow to Infinity or accidentally produce 
a NaN.)

On 05/01/2017 02:04 PM, Alexander Jones wrote:
> I hear this argument a lot but it strikes me with cognitive 
> dissonance! JSON defines a very intuitive notion of object 
> value-semantics - whether the serialized JSON is an equivalent string. 
> Granted that many value types are not supported by JSON, but it's a 
> trivial generalisation.
>
> Let's just give the above a name and get on with it. For 99% of use 
> cases it would be ideal, no?
>
> Thoughts?
>
> On 1 May 2017 at 20:58, Oriol _ <oriol-bugzilla at hotmail.com 
> <mailto:oriol-bugzilla at hotmail.com>> wrote:
>
>     This is not easy to generalize. Comparing objects is one thing
>     lots of people want, but not everybody needs the same kind of
>     comparison.
>     For example, you compare own property strings. But what about
>     symbols? Somebody might consider two objects to be different if
>     they have different symbol properties.
>     Or the opposite, somebody may think that checking enumerable
>     properties is enough, and non-enumerable ones can be skipped.
>     Then some property values might be objects. Are they compared with
>     === or recursively with this algorithm (be aware of cycles)?
>     Similarly, for the [[Prototype]]. Do inherited properties matter?
>     Should [[Prototype]]s be compared with === or recursively?
>     There is also the problem of getters: each time you read a
>     property, it might give a different value! You might want to get
>     the property descriptor and compare the values or the getter
>     functions.
>     And then there are proxies. Taking them into account, I don't
>     think there is any reasonable way to compare objects.
>
>     So I think it's better if each person writes the code that
>     compares objects according to their needs.
>
>     --Oriol
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170501/83c63947/attachment.html>