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

> No, if you do new CustomEvent the allocation happens in CustomEvent.

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

But I guess that's not how platform interfaces work. 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.

That latter model probably makes more sense when you have a hierarchy of exotic objects. ES in general doesn't seem to have that; the closest it has is GeneratorFunction deriving from Function but it looks like FunctionAllocate (i.e. what does the allocation inside the Function constructor) has hard-coded knowledge of generator functions baked in to it. This is somewhat predictable as ES seems to make an implicit assumption that all of an object's slots are fixed at creation time.

With this in mind I agree that we should do something specific to elements. Although, now I'm not sure what. I was thinking of just specifying a [PassThroughConstructor], but I guess that's not really what we want. We basically want to define that every HTML element class uses the same algorithm, which is currently only encoded in HTMLElement.

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 ..."

---
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-220731760