<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Le 12/08/2011 16:55, Tom Van Cutsem a écrit :
    <blockquote
cite="mid:CAKDfNj9WXm=eyRRB_LcJThk=51zpSWotSm+qkcFxuiZOJVWyEw@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">2011/8/12 Andreas Rossberg <span
          dir="ltr"><<a moz-do-not-send="true"
            href="mailto:rossberg@google.com">rossberg@google.com</a>></span><br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex;">
          <div class="im">On 12 August 2011 13:53, Tom Van Cutsem <<a
              moz-do-not-send="true" href="mailto:tomvc.be@gmail.com">tomvc.be@gmail.com</a>>
            wrote:<br>
            > I think I found a compelling and easy-to-understand<br>
            > rule for determining whether or not a trap needs access
            to proxy/receiver:<br>
            > if the trap deals with inherited properties, it needs
            access to |proxy|.<br>
            <br>
            [...]<br>
            <br>
          </div>
          Although that rule seems fairly simple, I still find a
          half/half<br>
          situation unnecessarily confusing and error-prone. I would
          strongly<br>
          vote for making the API consistent. That is, either equip all
          methods<br>
          with a proxy argument (preferably as first), or none.<font
            color="#888888"><br>
          </font></blockquote>
        <div><br>
        </div>
        <div>Despite the simple rule, I too would prefer passing |proxy|
          to all traps (but not as first argument), even though, as
          Brendan noted, it's not strictly necessary and consistency in
          one dimension sacrifices consistency in another. It would be
          good to hear more opinions on this.<br>
        </div>
      </div>
    </blockquote>
    We have identified that |proxy| could be used to retrieve the
    prototype.<br>
    What other "useful" information could be retrieved from |proxy|?<br>
    Its [[Prototype]], its [[Class]], its identity (as |this| for
    getters/setters in get/set traps and as WeakMap key, however this
    has never had a lot of support on es-discuss)?<br>
    [[call]] would be accessible via proxy() or proxy.call()<br>
    [[construct]] would be accessible via new proxy()<br>
    All other internal things seem accessible via the handler (|this|
    from within a handler method context).<br>
    Maybe that there is another dimension of inconsistency which is that
    internal properties and methods can be accessed via two things: the
    handler and the proxy.<br>
    "two things"... rather than one (the handler) as it was originally.<br>
    Hence my previous e-mail about bringing everything back to the
    handler (prototype, call, construct, etc.)<br>
    <br>
    Also, it's a bit strange that all traps can be changed dynamically
    while call and construct can't. Well, that's not entirely true: call
    and construct could contain some context in a closure that could
    change their behavior over time.<br>
    -----<br>
    var b = true;<br>
    <br>
    function f(){<br>
      if (b)<br>
        f1();<br>
      else<br>
        f2();<br>
    }<br>
    <br>
    b = Math.random() < 0.5;<br>
    -----<br>
    i can provide f as a call trap, it is not more "fixed" than any
    other trap provided in the handler.<br>
    <br>
    As another argument in favor of putting call and construct in the
    handler, there is the meta-handler-based membrane. With the current
    handlerMaker, the resulting object can still be called and
    constructed. I just gave above a solution for that issue, but having
    call and construct in the handler would allow the generic solution
    to work without extra effort.<br>
    <br>
    David<br>
  </body>
</html>