From: Ryosuke Niwa [mailto:rn...@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.

Reply via email to