<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Le 26/11/2012 19:37, Allen Wirfs-Brock
      a écrit :<br>
    </div>
    <blockquote
      cite="mid:ED2E66A3-9FE0-4AD1-8797-AF154A9D3460@wirfs-brock.com"
      type="cite"><br>
      <div>
        <div>On Nov 26, 2012, at 10:00 AM, Tom Van Cutsem wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div class="gmail_quote">2012/11/24 Allen Wirfs-Brock <span
              dir="ltr"><<a moz-do-not-send="true"
                href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span><br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div style="word-wrap:break-word"><br>
                <div>
                  <div class="im">
                    <div>I see that [2] call for filtering __proto__
                      access in Get/Put handlers.   I think that dealing
                      with it in a Get/SetInheritance handler would be a
                      much more efficient way to hand this extremely
                      rare operation.  Rather than filtering for it on
                      every property access, an handler that cares only
                      needs to worry about the actual
                      Get/SetInhertiance.</div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Hmm, so you're arguing that proxy.__proto__ would be
              equivalent to Object.getPrototypeOf(proxy), and trigger
              the "getPrototypeOf" trap, rather than triggering the
              "get" trap?</div>
            <div><br>
            </div>
            <div>I guess that more accurately reflects the magical
              behavior of __proto__.</div>
            <div><br>
            </div>
            <div>Paradoxically, this will move the filter check into the
              proxy implementation itself, to properly intercept
              proxy["__proto__"]. On first sight, this seems to
              introduce more overhead.</div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>We need to pin down exactly what backwards compatible
          semantics of "__proto__" we need to provide.</div>
        <div><br>
        </div>
        <div>My preference would be to recognize  expr.__proto__ as a
          syntactic form with its own runtime semantics.  That would
          exclude things like expr["__proto__"] and I'd be quite happy
          with that if it does have any real world compat issue.<br>
        </div>
      </div>
    </blockquote>
    The decoupling of [] and property access [1] could take care of
    expr["__proto__"].<br>
    What I mean by that is that the spec for __proto__ can be as it is
    now and could separate both forms. If [1] makes it to any version of
    ES6, it will be the way to explain the difference.<br>
    <br>
    David<br>
    <br>
    [1]
    <a class="moz-txt-link-freetext" href="http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation">http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation</a><br>
  </body>
</html>