<div class="gmail_quote">2011/9/6 Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com">erights@google.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Tue, Sep 6, 2011 at 8:08 AM, Tom Van Cutsem <span dir="ltr"><<a href="mailto:tomvc.be@gmail.com" target="_blank">tomvc.be@gmail.com</a>></span> wrote:<div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>[...]</div><div>1) Have fix() not just return a property descriptor map, but a tuple of [constructor, property descriptor map]. To create the instance it needs to become, the proxy invokes the returned constructor's "create" method with as first argument the proxy's prototype and as second argument the prop. desc. map.</div>



<div><br></div><div>For example:</div><div><br></div><div>fix: function(operation) {</div><div>  // I want to become an array</div><div>  return [Array, { ... } ];</div><div>}</div></div></blockquote><div><br></div></div>
<div>
Array.isArray and other [[Class]] checks (e.g., the Flanagan device of using ({}).toString.call) need to give stable answers. Especially because they currently always do give stable answers.</div></div></div></blockquote>
<div><br></div><div>Ok, that rules out this design.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>2) Add the constructor to use upon fixing as an additional argument to Proxy.create{Function}, e.g.:</div>


<div><br></div><div>var p = Proxy.create(handler, proto, Array);</div><div>// fix() trap will use Array.create</div><div><br></div><div>[...]</div>

<div><br></div><div>We could state that the "constructor" argument must be equal to Object, Array, and perhaps a handful of other primitive constructors, but that would probably rule out NodeList. How can we get some guarantee that a function is effectively going to produce and return a newborn object?</div>

</div></blockquote><div><br></div></div><div>How about we adapt ideas from the "<|" proposal? Proxy.create already takes a proto argument. The third argument could say whether the [[Class]] of the proxy should be "Object" or should be the same as that proto. No constructors.</div>
</div></div></blockquote><div><br></div><div>That would probably also allow Object.prototype.toString.call(proxy) to return, e.g. [object Array], which is another outstanding issue.</div><div><br></div><div>I can see this working for Object and Array. Functions are covered by function proxies. Do we need to consider other primitives?</div>
<div><br></div><div>I still don't see how it would work out for NodeList or other host objects. Then again, I don't know whether there is a use case that requires this.</div><div><br></div><div>Cheers,</div><div>Tom</div>
</div>