<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><ol><li>I think its easier to explain - it will actually result in a constructor on the prototype.</li>
<li>
The actual constructor function and the .constructor property really should always be in sync - this helps with that.</li><li>"new" doesn't have those benefits - people might expect to be able to call .new() like in ruby.</li>

<li>"new" conflicts with the new <object> proposal.</li></ol></div></div></blockquote><div>There are some minor practical considerations on the "constructor" side, and aesthetic considerations on the "new" side.  Instead of squaring off now, can we just agree to leave if off the table temporarily?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>I think that's ok. Just like I don't think there should be an implicit super call at the top of the constructor if you skip it. Sure Java and C# enforce this, but I don't think its really the JavaScript style. There are realistic use cases for doing something before you call super, or skipping a call to super. </div>
</div></blockquote><div><br></div><div>I can basically agree with you (although I don't see a use case for skipping the super constructor).  But because of ordering requirements this is going to shut the door forever on instance field initializers.  Nothing necessarily wrong with that, we just need to be aware.</div>
<div><br></div><div>kevin</div></div>