<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Le 01/03/2011 15:35, Tom Van Cutsem a écrit :
    <blockquote
      cite="mid:AANLkTinYXAJ2gUtThsQuRi6ybJsiaOo8-TGDYXiGFD+h@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>Hi,</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div text="#000000" bgcolor="#ffffff">Here is another idea:<br>
            Adding a 'currentProxy' property to the arguments object of
            a handler methods when it's called as a trap (otherwise, the
            method is just a regular function). It's very close to the
            idea of adding an argument without the
            inconvenient/embarassement of placing it. It's generic, so
            it solves the issue for future traps. It obviously comes to
            the price of some sort of inconsistency, because adding
            things to the arguments object hasn't been done before (not
            that i'd be aware of, at least).<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>With the introduction of the spread operator in Harmony,
          the intention is to move away from using |arguments|. I
          wouldn't want to tie the proxies proposal this tight to the
          |arguments| object. Also, as you note, there is no precedent
          for it. I would also claim that it still doesn't feel like a
          natural place to store the proxy.</div>
      </div>
    </blockquote>
    Ok. I didn't know the intention to go away from the arguments
    object.<br>
    <br>
    <blockquote
      cite="mid:AANLkTinYXAJ2gUtThsQuRi6ybJsiaOo8-TGDYXiGFD+h@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div> </div>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div text="#000000" bgcolor="#ffffff"> <br>
            Within a handler method, there would be a subtle difference.
            Let's take the example of a derived trap implementation (has
            trap):<br>
            --------------------------<br>
            var h = {<br>
            getPropertyDescriptor: function(name){return
            arguments.currentProxy;},<br>
            has: function(name) { return
            !!this.getPropertyDescriptor(name); }<br>
            }<br>
            var p = Proxy.create(h);<br>
            <br>
            'a' in p; // false<br>
            --------------------------<br>
            When 'has' is trapped, it calls the handler method like a
            regular method, so there is no special treatment to
            arguments (arguments.currentProxy === undefined =>
            !!this.getPropertyDescriptor(name) === false)<br>
            <br>
            If 'has' was implemented as:<br>
            has: function(name) { return
            !!Object.getPropertyDescriptor(arguments.currentProxy,
            name); }<br>
            then the 'getPropertyDescriptor' handler would be called as
            a trap, so 'currentProxy' would be 'magically' added to the
            arguments object.<br>
            <br>
            <br>
            I'm realizing that my idea raises a question that had no
            reason to exist before. <br>
            Before, proxy weren't accessible from handler methods, so in
            order to implement derived traps, one handler method could
            only have access to other handler methods through 'this'.
            However, if 'proxy' becomes accessible within handler
            methods (no matter how), it could be considered to
            reimplement derived traps with actual fundamental trap
            trapping. I would personnally feel this to be more
            consistent with the idea of a mapping between traps and
            internal methods.<br>
            However, as of today, besides my arguments-proxy-patching
            idea, I do not see how to notice a difference between
            'this.getPropertyDescriptor(/*proxy, */ name)' (proxy
            argument depending on how we give proxy access to handler
            methods) and being trapped on
            'Object.getPropertyDescriptor(proxy, name)'.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>There should not be a difference. Any code that has access
          to both a proxy and to its handler object can choose to either
          invoke the traps explicitly on the handler, or implicitly via
          the proxy object. I don't see why a trap should be able to
          distinguish both cases.</div>
      </div>
    </blockquote>
    I was just saying that I didn't see any way that they can
    distinguish and then implicitely asking if anyone else would see
    any. But the way you explain it make clear that there is no reason
    code could distinguish.<br>
    <br>
    On "should code be able to distinguish", I have no strong opinion.
    It might be some way to enrich the proxy API. Anyway, since it's not
    possible, the question can be forgotten for now.<br>
    <br>
    <br>
    <blockquote
      cite="mid:AANLkTinYXAJ2gUtThsQuRi6ybJsiaOo8-TGDYXiGFD+h@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>Of the proposals listed on the strawman wiki page, I prefer
          the "Proxy as additional argument" option. I think consistency
          between the traps and the Javascript code that they intercept
          is what matters most in practice, and what will minimize bugs
          for developers that are not familiar with spec. details. IOW,
          calls like "Object.defineProperty(proxy, name, pd)" would then
          be trapped by "function defineProperty(proxy, name, pd)
          {...}". Principle of least surprise and all that :-)</div>
      </div>
    </blockquote>
    Actually, under this option, you list "less consistent" as a con. <br>
    "Consistency" is used in two different points of view:<br>
    - The consistency listed as a con in the proxy handler API
    consistency<br>
    - The consistency you're talking in your paragraph is between the
    proxy handler API and surface syntax.<br>
    I tend to agree that<br>
    <br>
    <br>
    About the last option "Proxy as argument only for particular traps",
    I think that this option should be considered only if the method
    list contains at least all methods which use prototypal inheritance.
    This would grow the list to:<br>
    * getPropertyDescriptor<br>
    * getPropertyNames<br>
    * has<br>
    * get<br>
    * set<br>
    * enumerate<br>
    First, it makes sense, because in order to re-implement inheritance,
    there is a need to access prototype, which can only be done through
    Object.getPrototypeOf(proxy).<br>
    More practically, as an example, the default 'has' trap cannot pass
    'proxy' as an argument to the 'getPropertyDescriptor' trap if it
    hasn't itself a reference to the proxy. (actually, there is a
    similar issue with get set and enumerate)<br>
    It should be noted that this option doesn't solve the first
    motivating use case (shared handler) since some method are
    disadvantaged regarding, for instance, being able to store per-proxy
    state.<br>
    <br>
    Cheers,<br>
    <br>
    David<br>
    <br>
    <blockquote
      cite="mid:AANLkTinYXAJ2gUtThsQuRi6ybJsiaOo8-TGDYXiGFD+h@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
        </div>
        <div>Cheers,</div>
        <div>Tom</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div text="#000000" bgcolor="#ffffff"> <br>
            Cheers,<br>
            <font color="#888888"> <br>
              David</font>
            <div class="im"><br>
              <br>
              <br>
              <blockquote type="cite">
                <div><br>
                </div>
                <div>Cheers,</div>
                <div>Tom<br>
                  <br>
                  <div class="gmail_quote">2011/2/28 David Bruant <span
                      dir="ltr"><<a moz-do-not-send="true"
                        href="mailto:bruant@enseirb-matmeca.fr"
                        target="_blank">bruant@enseirb-matmeca.fr</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 text="#000000" bgcolor="#ffffff"> <font
                          size="-1">Hi,<br>
                          <br>
                          After reading this page (<a
                            moz-do-not-send="true"
href="http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy"
                            target="_blank">http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy</a>),


                          I thought of another idea.<br>
                          Maybe that instead of adding an argument to
                          all handler methods, we could add a property
                          to the handler.<br>
                          Each time a proxy p method m is trapped (with
                          handler h):<br>
                          - Object.defineProperty(h, </font><font
                          size="-1"> 'currentProxy'</font><font
                          size="-1">,  </font><font size="-1">{value:
                          p, configurable:true}</font><font size="-1">)<br>
                          - call the m trap (which can freely use this.</font><font
                          size="-1">currentProxy</font><font size="-1">)<br>
                          - delete h.</font><font size="-1">currentProxy
                          (that's why the property has to be
                          configurable)<br>
                          <br>
                          An implementation could run some static
                          analysis to see if </font><font size="-1">
                          the handler is an actual object and if this.</font><font
                          size="-1">currentProxy</font><small> is
                          actually used in the trap to avoid the
                          overhead of define+delete. They would have to
                          be performed if the handler is itself a proxy.<br>
                          In order to reserve the 'currentProxy' (no
                          strong conviction on the name. It could also
                          be 'proxy') name, Proxy.create and
                          Proxy.createFunction could throw an error is
                          such a property is already defined.<br>
                          <br>
                          On issue is that within a handler method, I
                          could do:<br>
                          {keys: function(){<br>
                              Object.defineProperty(this,
                          'currentProxy', {value: 'gotcha',
                          configurable:false});<br>
                              }<br>
                          }<br>
                          This is notoriously stupid, but it would make
                          the "inner delete" throw an error. The issue
                          I'm raising is that 'configurable' controls
                          both the fact that a property can be redefined
                          through Object.defineProperty and deleted.<br>
                          <br>
                          Anyway, this solution sweeps away any argument
                          positionning issue. It is very generic and for
                          sure, any trap current or future will need
                          access to the proxy, so it solves the problem
                          for potential future traps.<br>
                          On the other hand, there may be some property
                          configuration issues and maybe some
                          performance issue since the two additional
                          calls may be needed at each trap call (even
                          though static analysis could help out with
                          this).<br>
                          <br>
                          This idea is unperfect like the others, but it
                          might be worth investigating in that
                          direction.<br>
                          <br>
                          David<br>
                          <font size="-1"><small> </small></font></small>
                      </div>
                      <br>
                      _______________________________________________<br>
                      es-discuss mailing list<br>
                      <a moz-do-not-send="true"
                        href="mailto:es-discuss@mozilla.org"
                        target="_blank">es-discuss@mozilla.org</a><br>
                      <a moz-do-not-send="true"
                        href="https://mail.mozilla.org/listinfo/es-discuss"
                        target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
                      <br>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </blockquote>
              <br>
            </div>
          </div>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>