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