RE: Minimum viable custom elements

From: Ryosuke Niwa [mailto:rniwa@apple.com] 

> Unfortunately for developers, native syntax for inheritance in Stink 2.0 cannot be used to subclass views in Odour.

The native syntax for inheritance can definitely be used! You just can't override the constructor, since constructing a view is a very delicate operation. Instead, you can provide some code that runs during the constructor, by overriding a specific method.

I wouldn't call this incompatible, any more than saying that ASP.NET Page classes are incompatible with C# classes:

http://www.4guysfromrolla.com/articles/041305-1.aspx


(you define Page_Load instead of the constructor). I imagine I could find many other frameworks (perhaps ones written for Stink developers?) where when you use a framework and derive from a framework-provided base class, you can't override the framework's methods or constructors directly, but instead have to override provided hooks.

> If ES6 classes' constructor doesn't fundamentally work with custom elements, then why don't we change the design of ES6 classes.

We would essentially be saying that the design of ES6 classes should be built to support one particular construction pattern (two-stage construction), over any others. Why not design it to support three-stage construction? There are surely libraries that have more than two phases of boot-up.

One way to think about it is that there is a "base constructor" for all classes (corresponding, in spec language, to the definition of [[Construct]]), that in the newest TC39 design does the simplest thing possible. The DOM needs a more complicated setup. Shouldn't that be the DOM's responsibility to encode into *its* base constructor?

> Saying that TC39 doesn't have a time is like saying we can't make a spec change because WG has already decided to move the spec into REC by the end of the year in W3C.

That, I certainly agree with. Any process reasons brought up are bogus. But the technical arguments for "the simplest base constructor possible" in the language are pretty sound. They're in fact reasons that motivated TC39 to go into a last-minute redesign marathon over the holiday weeks, to get *away* from the more complicated "base constructor" that contained a two-stage allocation/initialization split.

Received on Thursday, 15 January 2015 23:18:18 UTC