<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 04/10/2012 20:35, Mark S. Miller a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CABHxS9gk2+w-+_JOvtUUWSC-Up14uOhQErkqMGrLd-oAjv=rwA@mail.gmail.com"
      type="cite">On Thu, Oct 4, 2012 at 8:40 AM, David Bruant <span
        dir="ltr"><<a moz-do-not-send="true"
          href="mailto:bruant.d@gmail.com" target="_blank">bruant.d@gmail.com</a>></span>
      wrote:<br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div class="gmail_quote">
            <div class="im">
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div class="gmail_quote">
                  <div>* It allows the target to be modified first, in
                    anticipation of the target being queried at the end
                    of the trap.</div>
                </div>
              </blockquote>
            </div>
            <div>Do we really need to change the target prototype before
              reporting a different prototype? </div>
            <div>IIRC for performance reasons, it's been decided to not
              perform any inheritance-related invariant check, so which
              object is in the prototype or reported as such does not
              really matter since it provides no guarantee for
              set/get/has traps. For these traps, any lie can be told
              for not-own properties. In that context, being forced to
              return a given prototype is a bit too much in my opinion
              since it's not an information client code can really rely
              on for anything</div>
            <div>Things are a bit different for non-extensible objects
              from which we can have stronger expectations (since
              setting __proto__ doesn't work for them)</div>
          </div>
        </blockquote>
      </div>
      <div><br>
      </div>
      <div>That last is really the point. It enforces that a proxy
        cannot appear to change its __proto__ unless it really can
        change the __proto__ of its target. Besides non-extensibility,
        another reason it may not be able to is that the relevant
        Object.prototype.__proto__ was deleted and the proxy's handler
        has no access to its original value.<br>
      </div>
    </blockquote>
    I'm not sure I understand your answer.<br>
    Should the invariant stand even for extensible proxies?<br>
    <br>
    David<br>
  </body>
</html>