On 7/17/15 2:03 PM, Travis Leithead wrote:
Something magical happens here. The use of super() is supposed to call
the constructor of the HTMLElement class—but that’s not a normal JS
class. It doesn’t have a defined constructor() method
Sure, but neither does Array. What super() actually does is get the
prototype of the current constructor and call it. So in your case:
class CustomElement extends HTMLElement {
constructor() {
super();
}
}
it would call the HTMLElement constructor.
Now there's a slight problem here, which is that HTMLElement is not
defined to have a constructor in the spec right now. We need to fix
that, clearly, for this subclassing of elements with constructors stuff
to make sense.
Also, as
has been pointed out, running the CustomElement constructor code
_/before/_ instantiating the actual element (at parse-time for example)
I'm not sure what "before" means here. In the hypothetical world in
which we call the CustomElement constructor from the parser, the parser
would do that, and get back an object. That would be the "actual element".
·Javascript classes are mutable—what if CustomElement’s proto chain is
mutated later?
Then you get something that may not be an HTMLElement when you construct
via it. Obviously consumers who care (like the parser, perhaps; though
it may only care about getting Element) would need to check and handle
that problem.
1.Native [internal] element is created with appropriate tag name,
attributes, etc.
2.JS constructor is called and provided the instance (as ‘this’)
The only problem with that is what Anne pointed out: there are some
proposed ES spec additions that would require that the initial JS object
allocation take the subclassing bits into account to determine which
immutable state it's preallocated with. Note that I'm not convinced
that means we need to call JS from the parser; just that's the problem
Anne is trying to solve.
Need to chew a bit on your XFooStartup proposal before I can comment on
it intelligently.
-Boris
