<!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">
    Le 22/03/2011 12:58, Tom Van Cutsem a écrit :
    <blockquote
      cite="mid:AANLkTikb8TOA1vOO4NzZhmAvLhiGq-aQhdTHRo6vfj9x@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <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"><small>Another way of
              solving the inconsistency I see in providing the 6
              "prototype-climbing" traps (</small><font size="-1">"getPropertyDescriptor",
              "getPropertyNames", "has", "get", "set" and "enumerate"</font><small>)
              and protecting Object.getPrototypeOf and instanceof could
              be to provide a softer version of proxies where these
              traps wouldn't be provided. Prototype-climbing internal
              methods would be delegated to the ECMAScript engine with
              the default behavior they have on objects (but still
              calling own traps when their algorithm requires them to).
              By design of this softer version, proxy writers would be
              ensured that inheritance will be done properly for them
              and they don't have to worry about it. They would just
              have to take care of the own properties "layer". (This
              paragraph is a slightly different topic. If you feel it
              requires its own thread, feel free to fork)</small></div>
        </blockquote>
        <div><br>
        </div>
        <div>I think this "softer version" already exists. If we can get
          agreement to turn getPropertyDescriptor and getPropertyNames
          into derived traps (see <<a moz-do-not-send="true"
href="http://wiki.ecmascript.org/doku.php?id=strawman:proxy_derived_traps">http://wiki.ecmascript.org/doku.php?id=strawman:proxy_derived_traps</a>>),
          then all of the prototype-climbing traps become derived. As
          such, proxy writers that stick to overriding only fundamental
          traps will only need to take care of the "own layer", and
          inheritance will be taken care of by the default
          implementation of the derived traps.<br>
        </div>
      </div>
    </blockquote>
    That's true. <br>
    However, I feel there is something more that may require the
    separation. <br>
    <br>
    Before going any further, I'd like to rename what I called "soft
    proxies" as "inheritance safe proxies", because that's what they
    would be by design. They would keep all (no exception) prototype
    chain-related invariants. Under the light of what Mark Miller said
    ("I just heard from Brendan today that Andreas Gal has encountered
    some DOM emulation issues that might make us want us to consider
    [the adoption of <a
      href="http://wiki.ecmascript.org/doku.php?id=strawman:proxy_instanceof">http://wiki.ecmascript.org/doku.php?id=strawman:proxy_instanceof</a>]
    sooner rather than later."), it appears that some prototype chain
    related invariants (relationship between instanceof and the internal
    [[Prototype]]) will disappear, because they prevent from
    implementing multiple inheritance while keeping consistency with
    instanceof.<br>
    <br>
    As I said, one inconsistency I currently see in the Proxy API is
    that proxies through proto-climbing traps can fool all inheritance
    mechanisms. Meanwhile, Object.getPrototypeOf and instanceof are kept
    safe (well, maybe not for long for instanceof). Basically, while the
    entire own properties API is fully trappable, the inheritance API is
    half trappable half locked. It gives me the feeling of something
    wrong. <br>
    Spliting in two APIs with one being "inheritance safe proxies" and
    the other giving more power on inheritance (the direction current
    proxies seem to follow) could be one solution to have two consistent
    APIs instead of one.<br>
    <br>
    One interesting difference is that I think the issue of data
    validation and massaging would have two different answers for both
    approaches. In current proxies, proto-climbing traps default
    behaviors are just conviniences in order to reduce the number of
    traps to be written. That's the reason why I argue that if you want
    to define your own internal consistency, you can get rid of default
    derived traps behaviors by overriding them. Consequently, data
    validation+massaging would just be "on your way", preventing you
    from fully defining your own internal consistency.<br>
    On the other hand, for inheritance safe proxies, this would be a
    different story. The inheritance internal methods have expectations
    and you cannot change that since you could not override them. You
    would have to fit within the model provided by regular objects and
    inheritance. Consequently, I would argue, for that case that data
    validation+massaging is necessary.<br>
    <br>
    After reviewing all the examples, it has given me the impression
    that all without exception could be implemented with inheritance
    safe proxies. With the expection of full forwarding proxies if these
    forward to a full proxy and attempts (not on the wiki) to implement
    multiple inheritance which require a different get trap. Otherwise,
    all examples currently using the get trap could achieve the same
    things with the getOwnPropertyDescriptor. It would be slightly more
    verobse though.<br>
    <br>
    Cheers,<br>
    <br>
    David<br>
  </body>
</html>