Re: [heycam/webidl] Proposal: allow subclasses of constructible built-ins to be constructed (#125)

> I was assuming a normal ES model where subclasses called super(), and the base-most constructor uses new.target to determine what to allocate.

That's not at all how things work at all in ES6 for builtins.  The `Array` constructor uses `ArrayCreate` no matter what `new.target` is.  Most other ES6 builtin constructors (`Map`, `Promise`, etc) use `OrdinaryCreateFromConstructor` but importantly pass it the list of internal slots to allocate.  In fact, all of the ES builtins are designed such that the list of internal slots is available at allocation time last I checked.  In none of those cases is the allocation behavior affected by the value of `new.target`; all that affects is the prototype of the object that gets created.

> It sounds like they do a single allocation (and branding process) in their most-derived constructor, and only run that constructor's logic, not any base class constructors.

Going back to ES builtins, the one case where there is inheritance is typed arrays.  The way these are done in ES6 is that all the typed array classes have the same set of internal slots and the typed array constructors do in fact delegate to their proto (note, dynamically; I'm not sure whether you were proposing dynamic or static delegation in the HTML element constructors).  Anyway, these all invoke `%TypedArray%` which starts at `new.target` and walks its proto chain looking for one of the typed array constructors.  If it finds one, it uses that to decide which sort of typed array to allocate.  The actual allocation is again done via IntegerIndexedObjectCreate  (passing in all the internal slot names, etc) and the type is just stored in an internal slot.

There are no examples of ES6 builtins where builtin A subclasses builtin B and the set of internal slots differs between them, so we don't have a great guide to go on...

Anyway, there are two ways to model this.  One way is that creating an object requires its full set of internal slots, and then the creation has to be done by something that has all that information.  In practice, that's the most-derived builtin constructor.  This is the general approach ES6 takes, and the way actual implementations work, I believe.  The other way is that you can dynamically add internal slots.  As a specification device, this works ok: you call your super constructor, it adds whatever internal slots and branding, then you add your own internal slots and your own branding.  The key is that we never have branding and internal slots diverge.  This doesn't match how implementations work, but _may_ make specification easier.  The danger is if this setup allows creation of specifications that are not exactly implementable, due to the conceptual mismatch.  But I think it's hard to do that in this case, as long as you don't add internal slots in weird conditional wa
 ys...

> Maybe I'll define [HTMLElementConstructor] in HTML, which says "the [[Construct]] behavior for this interface is as follows: ... algorithm currently only in HTMLElement goes here ..."

That might actually make sense, yes.  But, again, we want this to be the built-in function object steps and use the normal built-in function object [[Construct]], I think.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/125#issuecomment-220748683