<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Le 31/08/2011 13:24, Tom Van Cutsem a écrit :
    <blockquote
cite="mid:CAKDfNj9h4tbLaFFAGqx580SwkJTimU23z+Ct_hy-frG7Y8d0gw@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">2011/8/30 Brendan Eich <span dir="ltr"><<a
            moz-do-not-send="true" href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>></span><br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div style="word-wrap: break-word;">
            <div>
              <div class="im">
                <div>On Aug 30, 2011, at 2:16 PM, David Bruant wrote:</div>
                <blockquote type="cite">
                  <div bgcolor="#FFFFFF" text="#000000"> Actually that's
                    what current function proxies do by default (no
                    .prototype unless otherwise specified). My
                    suggestion is to put a .prototype by default with
                    keeping the option to opt-out (same with .length,
                    etc.)</div>
                </blockquote>
              </div>
              Right, of course function proxies have to trap in order to
              emulate .prototype and other properties.</div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Indeed, that was our intent: fproxy.prototype and
          fproxy.length are determined by the handler via the "get"
          trap.</div>
        <div>This should work fine for fproxy.prototype (and it is
          actually consulted when evaluating |obj instanceof fproxy|.)</div>
        <div><br>
        </div>
        <div>For fproxy.length, the handler object can only return the
          call trap's length if it has a reference to the call trap,
          which as David points out, in the general case it does not.
          OTOH, typically a function proxy will wrap some other target
          function f, in which case the handler would simply return
          f.length, so I don't know whether this issue is such a big
          deal.</div>
      </div>
    </blockquote>
    True. Still, a handler needs an access to the callTrap in order to
    retrieve its length in the general case. And with the current API,
    it may be impossible for an already created handler (not one created
    through a factory) to access to the callTrap, making impossible to
    access its .length and .prototype<br>
    I agree that the typical case is to wrap, but is it a sufficient
    reason for people not wrapping to not be able to properly emulate
    function.length?<br>
    <br>
    <blockquote
cite="mid:CAKDfNj9h4tbLaFFAGqx580SwkJTimU23z+Ct_hy-frG7Y8d0gw@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>If one wraps an existing function f using the default
          ForwardingHandler like so:</div>
        <div>var fproxy = Proxy.createFunction(new ForwardingHandler(f),
          f);</div>
      </div>
    </blockquote>
    Alternatively, i suggested earlier this summer [1] to put callTrap
    and constructTrap as part of the handler. This which would solve the
    problem of a handler having access to the callTrap ("this.call" from
    any other trap) and would also solve the question "what if
    handler.call.length !== handler.construct.length?" which would be
    left to the author discretion.<br>
    <br>
    David<br>
    <br>
    [1]
    <a class="moz-txt-link-freetext" href="https://mail.mozilla.org/pipermail/es-discuss/2011-August/016247.html">https://mail.mozilla.org/pipermail/es-discuss/2011-August/016247.html</a><br>
  </body>
</html>