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 _ <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
