<br><br><div class="gmail_quote">On Tue, Mar 27, 2012 at 1:09 PM, David Herman <span dir="ltr"><<a href="mailto:dherman@mozilla.com" target="_blank">dherman@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Mar 26, 2012, at 10:32 PM, Brendan Eich wrote:<br>
<br>
>> 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.<br>


><br>
> The issue is "what is the right way?" I agree that classes shouldn't be too little veneer on oonstructor functions, though. Locking down the class constructor's .prototype is ok with me. It helps us move toward self-hosting the built-ins.<br>


<br>
</div>Does it? It's strictly more expressive to leave it unlocked; you can always use Object.defineProperty to lock it down after the fact. That should be enough to self-host the built-ins, unless I'm missing something.<br>


<br>
What I don't like about forcing everyone to use .constructor is that maybe they don't want their class to expose the constructor. Sometimes you want to build an abstraction that maintains control over its instances. You might want to use the classy constructor pattern internally, but only expose abstract API's that internally construct instances, and then you don't want people mucking with the constructor. Were it up to me, I'd prefer a more mirror-based approach for exposing the constructor of instances, so the creator of the API can control whether they want to expose it. I recognize the C.prototype.constructor idiom already exists, but it's a weak idiom. I'm not crazy about the idea of strengthening a problematic but currently unreliable and rarely used idiom.<br>

</blockquote><div><br></div><div>Removing/hiding it is just about the only reason I can think of touching it. Right now its a half baked promise of what the constructor is. I would like to have it either be correct or not there at all. I mean, yes, I suppose you could have some tricks with changing it to something else, but to me its mostly only useful at all if it can be relied on. This would be one step toward making it reliable. OTOH, I can see how it would be useful to remove it. Can we make it writable:false, configurable:true? Of course, that would only be a minor deterrent from changing it around, but maybe just enough?</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">
<br>
Dave<br>
<br>
</blockquote></div><br>