<div dir="ltr">No I was not proposing that it actually *be* stringified-comparison... or in any way be related to the JSON global.<div><br></div><div>* Property order would not be important for equality. Precedent is set by common sense.</div><div>* Reference semantics (i.e. visitation) would be exactly as you'd expect - look at Python's `dict` implementation for IMO the only obvious answer.</div><div>* I acknowledged specifically that JSON does not support all types, just use SameValueZero for primitives and be done with it.</div><div>* Cycles are a subset of all possible reference semantics.</div><div>* Getters should be called. It already works for JSON and I don't hear anyone complaining about it. (Maybe I wasn't listening?) - same for prototype chain questions...</div><div><br></div><div>That said, most of these questions evaporate if people would just start using Map for things. AFAIAC the main reason people don't is due to the absence of a Map literal and JSON parsing tending to give you Object back instead of a more appropriate type without such weirdness as prototypes and property descriptors (yes, I went there!).</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 May 2017 at 22:55, Steve Fink <span dir="ltr"><<a href="mailto:sphink@gmail.com" target="_blank">sphink@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_8275991891804120093moz-cite-prefix">It would be nice to have *something*
      for this. Some remaining problems I see with using JSON
      serialization, let's call it JSON.isEqual:<br>
       - JS has order, JSON does not<br>
       - JSON lacks NaN, +/-Infinity (and JSON.stringify maps these to
      null, which means JSON.isEqual({x: 0/0}, {x: 1/0}))<br>
       - cycles<br>
       - ...and everything under your "trivial generalisation"<br>
      <br>
      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).<br>
      <br>
      <br>
      Also, what is<br>
      <br>
          var x = 4;<br>
          JSON.isEqual({get foo() { return x++; }}, {foo: 4})<br>
      <br>
      ? If you went purely by "whatever JSON.stringify would return",
      then this would be true once and false afterwards.<br>
      <br>
      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.<br>
      <br>
      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.)<span class=""><br>
      <br>
      On 05/01/2017 02:04 PM, Alexander Jones wrote:<br>
    </span></div><span class="">
    <blockquote type="cite">
      <div dir="ltr">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.<br>
        <br>
        Let's just give the above a name and get on with it. For 99% of
        use cases it would be ideal, no?<br>
        <br>
        Thoughts?</div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On 1 May 2017 at 20:58, Oriol _ <span dir="ltr"><<a href="mailto:oriol-bugzilla@hotmail.com" target="_blank">oriol-bugzilla@hotmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr">
              <div id="m_8275991891804120093m_4091070769360107565divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir="ltr">
                <div>This is not easy to generalize. Comparing objects
                  is one thing lots of people want, but not everybody
                  needs the same kind of comparison.<br>
                  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.<br>
                  Or the opposite, somebody may think that checking
                  enumerable properties is enough, and non-enumerable
                  ones can be skipped.</div>
                <div>Then some property values might be objects. Are
                  they compared with === or recursively with this
                  algorithm (be aware of cycles)?</div>
                <div>Similarly, for the [[Prototype]]. Do inherited
                  properties matter? Should <span>
                    [[Prototype]]</span>s be compared with <span>=== or
                    recursively</span>?<br>
                  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.<br>
                  And then there are proxies. Taking them into account,
                  I don't think there is any reasonable way to compare
                  objects.<br>
                  <br>
                  So I think it's better if each person writes the code
                  that compares objects according to their needs.<span class="m_8275991891804120093HOEnZb"><font color="#888888"><br>
                      <br>
                      --Oriol</font></span></div>
              </div>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  </span></div>

<br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>