Finding a "safety syntax" for classes

Russell Leggett russell.leggett at
Thu Mar 22 21:45:30 PDT 2012

On Fri, Mar 23, 2012 at 12:30 AM, Brendan Eich <brendan at> wrote:

> Brendan Eich wrote:
>> Allen has argued against hoisting, based on the extends clause being an
>> evaluated expression.
> Also (if included) based on static property initializers being evaluated,
> intuitively in declaration/statement order, but if you hoist the class when
> do you evaluate the statics' inits?

This is what Allen said about hoisting for this spec (Its been a long
thread, not sure if you missed this.):

========== From Allen ============================
Regarding Dave's concern:
On Mar 20, 2012, at 11:55 AM, David Herman wrote:

I can mostly dig it -- I've been trying to encourage minimal classes for
quite some time now.

The part that I'm least happy about is that this doesn't allow for
declarative private methods, because if we had the computed syntax like
what we're adding to object literals, it would clash with hoisting:

        let priv = new Name();
        class C {
            // oops, priv is still undefined!!
            [priv](x, y, z) {
                return x * y / z

Dave, It shouldn't be an issue.  As has been discussed in other threads
(and at least one TC39 F2F) hoisting class definitions and immediately
initializing them the way we do with functions just doesn't work. Well,
more precisely, it doesn't work for full featured class declarations with
things like initialized data properties (class or instance side).  Maybe we
could get away with it with this limited form but then that would be future
hostile to future extensions that try to grow it into a full bells and
whistles class declaration.

We can live quite nicely with treating class declaration like const
declarations.  The name is logically hoisted so it is visible over the
lexical scope, but the name is temporally dead until the class declaration
is executed, in statement sequence, as an initializer.  That means that we
can have circular references between classes and forward references in
inner functions to classes.  The class declaration just need to be
initialized before any such reference is actually evaluated. Its TDZ for

Practically, that means that super classes declarations have to appear in
the text before subclasses and that you probably can't tuck all your class
declaration at the end of the block/function (yuck, anyway) like you can
with function declarations.  I think we can live fine with that.

Regarding privates, if classes are initialized in that manner there
shouldn't be any problem with the pattern you use for in your example
above.  It works exactly the same as for object literals.

Dave responded with being pretty happy about that resolution:

"Y'know, I think I'm about sold. Somehow it just seemed obvious to me that
classes should be pre-initialized like functions. But just about every time
something seems obvious to me I'm wrong. I should learn to trust the
opposite of my instincts. ;)

Seriously, though, your argument for TDZ makes sense to me."

FWIW, it sits well with me also.

- Russ

> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list