Finding a "safety syntax" for classes

Russell Leggett russell.leggett at gmail.com
Tue Mar 27 10:57:57 PDT 2012


On Tue, Mar 27, 2012 at 1:09 PM, David Herman <dherman at mozilla.com> wrote:

> 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.
>

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?

- Russ


>
> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120327/b875fa1f/attachment.html>


More information about the es-discuss mailing list