From: [email protected] <[email protected]> on behalf of Erik Arvidsson <[email protected]>
> On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren <[email protected]> wrote: > >> I think Ryosuke has a point here though. ES6 brings subclassing to the >> platform, but are not even close to reimagining the platform in terms of >> that. > > ES6 does not bring sub classing to the table. It has been there all along > (since ES1) and WebIDL heavily uses it. > > > Maybe I'm missing your point? Perhaps the situation is better stated as: ES6 brings a mechanism for creating exotic objects to the table, without opting out of the normal JavaScript meta-object protocol and inheritance model. (Namely, by returning exotic objects from @@create.) Somewhat relatedly, it also brings mechanisms for truly private state via weak maps, which was not possible for non-exotic prototype-using objects before ES6, and finally it allows you to create a large class of exotic objects that you couldn't previously, via proxies. All this means we are now much more capable of expressing WebIDL-derived APIs in terms of the same JavaScript semantics programmers have access to, whereas in the ES5 timeframe only spec-writers and implementers had access to those. As such it is possible to create such APIs that allow subclassing by using these new JavaScript constructs to expose their lifecycle and internals, whereas before they would often simply opt-out of trying to expose a usable JavaScript interface, by e.g. throwing errors whenever people tried to compose them with normal JavaScript concepts like subclassing. The task of retrofitting this kind of support onto the platform is another matter entirely. For example, WebIDL doesn't have an easy way to express `return new this.constructor(...)`---as a subclassing-friendly class would often do---as a result of its declarative type-ish nature. We have had related discussions when defining [Elements][1], and they were never truly resolved. Other places this has cropped up include promises and streams, both of which are designed in subclassing-friendly fashion, but at the price of using ES formalism instead of WebIDL. This is probably just a matter of people putting in the right work to make WebIDL, and the relevant specs consuming it, better. But it's a large task that's still underway. Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing). [1]: http://dom.spec.whatwg.org/#collections:-elements
