How to fix the `class` keyword

Kevin Smith zenparsing at
Wed Mar 4 22:10:41 UTC 2015

> ​This decision does not help in making DOM subclassable. It doesn't
> simply or easily integrate into all the existing and somewhat common OOP
> patterns in user land.

I don't understand these sentences - can you explain?  As far as I'm aware,
the current design does enable subclassing host objects.

What built-ins are we talking about then? The decision to fork things here
> seems MOSTLY motivated by a desire to support `class extends Array{}`

Well, any subclassing design would have to support JS builtins, obviously.

> There had to be a better way.

Not really.  If there were, we wouldn't have made such big a last-minute
change.  Other than not having the ability to "call" a class constructor,
what specifically are your concerns with the design?

> On the issue of calling class constructors, I would AT LEAST have
> preferred implicit new on all calls to class constructors.

Some people want that, and it's a pattern that can in principle be
supported by a future version of the language.  However, I don't believe
that it's the right default.  By having a default "call" behavior (other
than throwing), the addition of any custom "call" behavior to a class
definition will result in a breaking change for clients of that class.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list