On Mar 26, 2012, at 10:32 PM, Brendan Eich wrote: >> 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. > > 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.
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. 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. Dave _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
