How to fix the `class` keyword

Kevin Smith zenparsing at gmail.com
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: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150304/b9f0bf03/attachment.html>


More information about the es-discuss mailing list