Finding a "safety syntax" for classes

Brendan Eich brendan at
Mon Mar 26 22:32:40 PDT 2012

Russell Leggett wrote:
>     Finally, regarding:
> >>
> >>>
> >>>    d) an explicit 'constructor' method overrides the implicit
>     creation of the 'constructor' method but does not define the
>     constructor function
> >>>
> >>> 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.
> >>
> >> 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)
>     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

[Allen: extra .prototype on the left of ===, right?]

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

ES1 did that because implementation(s) possibly not including my "Mocha" 
in Netscape 2 but probably including IE3-4 JScript did that, because (if 
I can recall correctly) the built-ins constructors' .prototype property 
was used to find "the original value of Object.prototype" or "the 
original value of Array.prototype" given an internal memo that strongly 
referenced Object or Array, e.g. Without this, you'd need two internal 
memos, one for the ctor and one for its original .prototype value.

Kind of a dopey reason, but there it is.

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


More information about the es-discuss mailing list