>
> 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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
