<div class="gmail_quote">On Fri, Aug 12, 2011 at 07:51, Tom Van Cutsem <span dir="ltr"><<a href="mailto:tomvc.be@gmail.com">tomvc.be@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div class="im">2011/8/12 David Bruant <span dir="ltr"><<a href="mailto:david.bruant@labri.fr" target="_blank">david.bruant@labri.fr</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



  
    
  
  <div bgcolor="#FFFFFF" text="#000000">Regarding [[prototype]], handler.prototype could be just a
    initialzation value for a copy of the handler, or handler.prototype
    could be imposed to be a non-configurable, non-writable data
    property (TypeError if not the case) which will not require to do a
    handler copy.</div></blockquote></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    handler.call and handler.construct would have the rules that
    callTrap and constructTrap have. And typeof Proxy.create(handler)
    === 'function' <=> typeof handler.call === 'function' (to fit
    the ES5.1 definition of a function)<br></div></blockquote><div><br></div></div><div>I see your point but still prefer the current API. |Proxy.create(handler, proto)| makes it much clearer that |proto| is intended to be fixed at creation time than requiring |handler| to define a non-writable data property named "prototype".</div>

</div></blockquote><div><br></div><div>This reminds me of what I did in my revision of the E proxy API. If it were to be the case that the proxy is completely defined by a single handler, then it would be (less im)plausible to have it be the case that</div>

<div><br></div><div>  Proxy.create(handler) === Proxy.create(handler)</div><div><br></div><div>That is, a proxy's <i>identity</i> is fully specified by its parameters, the handler. In the E context this has benefits for our equality semantics and garbage collection. If this were the case in JavaScript, it would mean that traps would never need a proxy parameter, because Proxy.create(this) would substitute for it. (The handler methods in E indeed don't get the proxy as a parameter.)</div>

<div><br></div><div>You probably don't want to do this, but the observation was interesting to me.</div></div>