<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Finally, regarding:<br>
>><br>
>>><br>
>>>    d) an explicit 'constructor' method overrides the implicit creation of the 'constructor' method but does not define the constructor function<br>
>>><br>
>>> Why d)? Remember, the .constructor idiom is a *very weak* idiom that many JS programs don't follow. If a JS program has some reason to use 'constructor' for a different purpose, trust them.<br>
>><br>
>> I believe the constructor idiom is most commonly not followed today when the prototype property of a function is set to a new object (perhaps defined using an object literal) and correctly dynamically setting the "constructor" property is an extra step that is easily forgotten (an usually as no ill-effects)<br>

<br>
I really don't like d) very much at all.  I think one of the advantages that use of class declaration can offer  is a higher integrity implementation of the latent ES class model.   In particular, it could more strongly enforce the <ctor>.prototype === <ctor>.prototype.constructor invariant.  I don't think a class declaration should be allowed to set the prototype's constructor property to anything other than the actual class object (ie constructor function). It also should make <ctor>.prototype writable:false and configurable: false, just like is done for all of the chapter 15 constructors. In addition, I suggest that we should go one step further and also make <ctor>.prototype.constructor writable:false and configurable: false.  It isn't clear to me why ES1 chapter 15 made all <ctor>.prototype ReadOnly/DontDelete but didn't do the same for chapter 15 <ctor>.prototype.constructor properties.)Allen<br>
</blockquote><div><br></div><div>+1</div><div><br></div><div>This is actually one of the reasons I still come down on constructor over new - I'd really like to discourage screwing around with <ctor>.prototype.constructor. That always felt like a major wart IMO. Making it ReadOnly/DontDelete would be icing on the cake. Not sure if we can squeeze it into max/min, but I like it. Classes are a leaky abstraction, as you said, but I think the major gain is making it easy to do things the right way, even if we don't really add much functionality.</div>
<div><br></div><div>- Russ</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Allen<br>
<br>
<br>
</font></span></blockquote></div><br>