<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Le 02/12/2012 17:27, Tom Van Cutsem a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CAKDfNj9Ld+w4per038F2=EKQTXH9WRc71Uwo0=v+FWNKwCc+FQ@mail.gmail.com"
      type="cite">2012/11/28 David Bruant <span dir="ltr"><<a
          moz-do-not-send="true" href="mailto:bruant.d@gmail.com"
          target="_blank">bruant.d@gmail.com</a>></span><br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div text="#000000" bgcolor="#FFFFFF">
            <div>
              <blockquote type="cite"> I don't understand why a unique
                token per trap invocation would be necessary.<br>
              </blockquote>
            </div>
            I still don't understand this point.<br>
            I've gone spelunking. I've found:<br>
            * the wiki page [1] (reflecting July meeting) which mentions
            that returning undefined would express "I don't know the
            private name, please forward"<br>
            * Confirmed on July 31st [2].<br>
            * Introduction of the idea of putting the verification of
            known names somewhere else than for each trap return [3].
            Some discussion in between about this idea. Introduction of
            the idea of adding a third argument [4] after which I think
            stops all discussions about returning something in traps to
            prove knowledge of a private name or forwarding when not
            knowing.<br>
            <br>
            I don't remember the point about a token per trap invocation
            and I haven't been able to find it (but I haven't read
            everything).<br>
            <br>
            In any case, for "throw ForwardToTarget", I don't see why it
            would be necessary. It seems it would work unambiguously
            with meta-handlers, with target-as-a-proxy or with
            manipulate-any-other-proxy-inside-a-trap (which
            target-as-a-proxy is an instance of).</div>
        </blockquote>
        <div><br>
        </div>
        <div>I think throwing a special token, as is done with
          StopIteration would probably work in practice (little risk of
          confusing it with a legitimately returned value). However, it
          does require every trap invocation to be wrapped in a
          try-catch block to potentially catch that error.</div>
      </div>
    </blockquote>
    Yes and no. The "try-catch" is inside the engine, very much like for
    StorIteration in for-of loops.<br>
    In case current implementations had performance drawbacks, I feel
    they could special-case when they know they are calling a function
    in the context of a particular protocol (iterator or proxy trap for
    instance).<br>
    <br>
    <blockquote
cite="mid:CAKDfNj9Ld+w4per038F2=EKQTXH9WRc71Uwo0=v+FWNKwCc+FQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>Maybe I'm too influenced by the JVM, but my understanding
          is that wrapping every call to a trap with a try-catch block
          won't be free.</div>
      </div>
    </blockquote>
    The more interesting question is whether it would be significantly
    cheaper than 'returning a value+invariant checks' because that's the
    reason I suggested the addition of "throw ForwardToTarget".<br>
    <br>
    <blockquote
cite="mid:CAKDfNj9Ld+w4per038F2=EKQTXH9WRc71Uwo0=v+FWNKwCc+FQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>Perhaps implementors can comment.<br>
        </div>
      </div>
    </blockquote>
    Yep.<br>
    <br>
    David<br>
  </body>
</html>