Object.isEqual

[Alexander Jones]

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> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170501/84454395/attachment.html>