<!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 text="#000000" bgcolor="#ffffff">
    I personnally don't have any strong conviction on the matter (which
    object should carry the function if any). But as I wanted to get rid
    of a part of the terminology that had been used in a method name
    (<a class="moz-txt-link-freetext" href="http://wiki.ecmascript.org/doku.php?id=harmony:proxies#detecting_proxy_objects">http://wiki.ecmascript.org/doku.php?id=harmony:proxies#detecting_proxy_objects</a>)
    I just thought it would be fair to mention it and propose a solution
    to it. <br>
    There is no emergency though. In the proposal is written "The
    current consensus is not to provide this method as it directly
    breaks “transparent” virtualization of objects".<br>
    <br>
    David<br>
    <br>
    Le 13/03/2011 21:32, Brendan Eich a écrit :
    <blockquote
      cite="mid:90BB0EAF-DA4C-492E-8754-34E057B81B3A@mozilla.com"
      type="cite">I buy it.
      <div><br>
      </div>
      <div>I also cringe a little at Array.isArray, and therefore at
        Proxy.isProxy, in the pre-modules world ES5 and the proxies
        proposal inhabit. These seem like tautological predicates, and
        Object.isArray is prettier and more fitting in my view. But this
        is a tiny nit to pick. If you buy it, then Object.isProxy would
        be the predicate.</div>
      <div><br>
      </div>
      <div>OTOH, with modules we would *not* put isProxy on poor old
        Object, and one would want isProxy to be an export, along with
        create, createFunction, Handler, etc., from the standard Proxy
        module. So at this point I don't propose Object.isProxy.</div>
      <div><br>
      </div>
      <div>Whee, naming.<br>
        <div><br>
        </div>
        <div>/be</div>
        <div><br>
          <div>
            <div>On Mar 13, 2011, at 12:08 PM, David Bruant wrote:</div>
            <br class="Apple-interchange-newline">
            <blockquote type="cite">
              <div text="#000000" bgcolor="#ffffff"> <font size="-1">Hi,<br>
                  <br>
                  I would like to discuss the terminology of the
                  proposal and the two states of a proxy: trapping or
                  fixed.<br>
                  In order to discuss, here is a little example:<br>
                  ---------------------------------<br>
                  var o = {};<br>
                  var p = Proxy.create( forwardingHandler(o) );<br>
                  p.a = 1;<br>
                  o.b = 2;<br>
                  p.c = 3;<br>
                  o.d = 4;<br>
                  /* For all x in [a,b,c,d], we have (p[x] === o[x]) and
                  (p.hasOwnProperty(x) iff </font><font size="-1">o.hasOwnProperty(x)</font><small>)
                  */</small><br>
                <font size="-1"><br>
                  Object.preventExtension(p); // The "proxy" becomes
                  "fixed"<br>
                  <br>
                  delete o.a;<br>
                  delete p.b;<br>
                  // o is like {b:2, c:3, d:4} while p is like {a:1, </font><font
                  size="-1">c:3, d:4</font><font size="-1">}<br>
                  // o and p have lost "synchronicity". p is an object
                  with its own independent life.<br>
                  ----------------------------------<br>
                  <br>
                  After the Object.preventExtension|seal|freeze call, p
                  isn't a proxy anymore. It becomes a regular object.
                  None of what used to be p's traps when it /was/ a
                  proxy is going to be called anymore through p
                  surface-syntax iteraction. After the call to a
                  succeeding (non-throwing) fix trap, what we have falls
                  under the definition of an Object as known in ES5 (and
                  previously). Another way to put it is that there is no
                  way for an external program to distinguish if p is a
                  proxy or an object (unless this external program had
                  overriden Proxy.create beforehand).<br>
                  <br>
                  The way I see it, a proxy is trapping and that's it.
                  What is "fixed" is an object, because the proxy has
                  lost all its "magic" (and cannot get it back by
                  design).<br>
                  <br>
                  In my opinion, we should stop talking of proxies as
                  "fixed" and stop using this terminology because it may
                  cause confusion.<br>
                  If there is an agreement on this, I'd suggest</font><font
                  size="-1"> to rename</font><font size="-1"> the
                  Proxy.isTrapping method as Proxy.isProxy since as I
                  understand it, saying that a proxy is trapping is a
                  tautology.<br>
                  <br>
                  What's your opinion?<br>
                  <br>
                  David<br>
                </font> </div>
              _______________________________________________<br>
              es-discuss mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
              <a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a><br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>