Is there a missing step in that outlined algorithm? Where is [[Prototype]] set?<div><br></div><div>So roughly speaking, Foo.[[Constructor]](...args) would be defined as:</div><div>1) Let creator be Foo.[[Get]](@@create)</div>

<div>2 ) Let newObj be creator.call(foo).  //Foo is passed as the this value to @@create</div><div><br></div><div>2.5) Call newObj.[[SetInheritance]](Foo.prototype)</div><div><br></div><div>3)  Let ctorResult be Foo.[[call]](newObj,args)</div>

<div>4)  If Type(ctorResult) is Object, return ctorResult</div><div>5) else return newObj</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 3, 2012 at 6:52 PM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Dec 3, 2012, at 3:03 PM, Jason Orendorff wrote:</div>

<br><blockquote type="cite">On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span> wrote:<br><div class="gmail_extra">

<div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">The simplification I've thought about is eliminating [[Construct]] as an internal method/Proxy trap and just making the call @@Create/call consturctor sequence the evaluation semantics of the new operator.  But I've not yet convinced myself that this is sufficient to capture all of the "called as constructor"/"called as a function" semantic silliness that some chapter 15 built-ins have. I'm also not sure that DOM and friends don't have other dependencies on a reified [[Construt]]<br>



</div></blockquote><div><br>The simplification I had in mind was changing [[Construct]] from an internal method/Proxy trap to an ordinary .@@construct method. There would be a @@construct/constructor split rather than a [[Construct]]/@@create/constructor split.<br>


<br>But on reflection, it didn't seem like that would be simpler in practice. Having two separately hookable phases of object construction is just right. A class can easily customize either behavior in a way that not only works, but will still work when the class is subclassed further.<br>


<br>-j<br></div></div></div>
</blockquote></div><br></div></div><div>OK, so it sounds like we have a plan. I'll update the spec. to use @@create.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Allen</div></font></span></div>

<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>erik<br>
</div>