<!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 30/01/2011 16:58, Tom Van Cutsem a &eacute;crit&nbsp;:
    <blockquote
      cite="mid:AANLkTin_RVffBgoysDHvPWEoMYhjQo32tRdUi7B2ysZw@mail.gmail.com"
      type="cite"><br>
      <div class="gmail_quote">2011/1/28 David Bruant <span dir="ltr">&lt;<a
            moz-do-not-send="true"
            href="mailto:bruant@enseirb-matmeca.fr">bruant@enseirb-matmeca.fr</a>&gt;</span>
        <div>&nbsp;</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"><font size="-1"> <br>
              Based on that definition, we could have a stronger
              definition of derived traps:<br>
              Derived trap are defined as ES code using fundamental
              traps in order to respect the forwarding proxy definition.
              Before going any further, I'd like to say that it's
              already the case :-) In my opinion, that was the rational
              behind Mark Miller's "coherent behavior to fall back to"
              idea of what should be derived or fundamental. Coherent
              with what? With what we expect from native objects.<br>
              To solve my problem with proxyArrays, I got rid of all
              derived traps definitions in the forwarding proxy code and
              it worked perfectly. It could make sense to do exactly the
              same with the default proxy forwarding handler, otherwise,
              people who just want to implement a fundamental trap (like
              I did) will have to reimplement all derived traps
              depending on the fundamental and it is very likely that
              their reimplementation will be the derived trap default
              definition.<br>
            </font></div>
        </blockquote>
        <div><br>
        </div>
        <div>Very interesting observation. So the issue is that the
          derived traps of the "default forwarding handler" have two
          possible default implementations:</div>
        <div>a) forward the derived operation to the 'target' (that is
          how they are specified now)</div>
        <div>b) implement the "default" semantics in terms of the
          fundamental forwarding traps (or equivalently, the default
          forwarding handler has no derived traps)</div>
        <div><br>
        </div>
        <div>The problem with a) is that child objects of the default
          forwarding handler that override a fundamental trap must
          actually also override all derived traps that depend on it. In
          some cases, the trap implementor will want to do this anyway
          since the derived traps may allow a more efficient
          implementation, but if not, then indeed the programmer must
          either reimplement the default semantics, or delete the
          inherited derived trap.</div>
        <div><br>
        </div>
        <div>The problem with b) is that if the "target" object to which
          the proxy forwards is itself a proxy p2, then p2's derived
          traps will never be called. Instead, only p2's fundamental
          traps will be called. Things won't break, but it is suboptimal
          if p2 has ad hoc (presumably more efficient) implementations
          for its derived traps. Presumably, even if "target" is a
          native object, option a) is more efficient than defaulting to
          the fundamental operations.</div>
        <div><br>
        </div>
        <div>I have no good suggestion yet for how to address both
          issues. One way out would be to provide two default forwarding
          handlers (e.g. a FundamentalHandler that only defines the
          fundamental traps (and hence has b) semantics for its derived
          traps), and a DerivedHandler that inherits from the
          FundamentalHandler that adds the derived traps with a)
          semantics). Depending on the required semantics, the
          programmer can make his/her custom handler inherit from either
          one.&nbsp;But maybe this is just too complex a solution.<br>
        </div>
      </div>
    </blockquote>
    I do not have a strong opinion on the complexity of the solution,
    but i find it quite elegant. It solves both problems and keeps being
    consistent with the handler model by using inheritance.<br>
    <br>
    If I just had one thing to say it would only be about the naming.
    "DerivedHandler" could confuse programmers who could think that a
    DerivedHandler only defines derived traps while the derived traps
    are only the own properties. I think that "Handler" could be kept as
    the name, only defining derived traps as own properties and
    inheriting fundamental from FundamentalHandler.<br>
    <br>
    David<br>
  </body>
</html>