-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should other specs indicate that they create built-in functions that support [[Construct]]? #2209
Comments
Within the definition of builtin functions, webidl saying "constructor steps" seems like enough to satisfy ecma262. Confusion beyond that (for the web editors) could probably be handled by a note saying "this creates a function with a [[Construct]] slot because we identify it as such". |
(Side note: The ES spec defines the operation |
Good question, I'll bring this up in the next editor call. I like the direction @jmdyck is going with. Where the other spec built-ins are ordinary (most of the time, I hope?), @domenic, is there a concrete need for, or an example of, an exotic built-in constructor that I can look at? |
MakeConstructor is currently only valid on ECMAScript functions, since it implies OrdinaryCallEvaluateBody |
Ah yes, good point. Then I think it's most clear to add a path to |
+1, that would be very nice and explicit!
I'm not sure what this is exactly getting at. From what I can tell of the current spec, every built-in function object is exotic:
and built-in functions have the [[Call]] from 9.3.1, not 9.2.1. |
That’s only if they’re not implemented using self‑hosted JS, like what SpiderMonkey does for some of its implementation. |
Sorry, the question was worded confusingly. I was wondering if there is an example of a built-in constructor in other specs where the [[Construct]] behavior is not a simple wrapper around calling [[Call]]. That is, are there examples where the [[Call]] behavior is completely separate from [[Construct]] behavior? But I think your first sentence actually answers my question: "...we've come to the conclusion that all web platform classes should have a [[Construct]], even if it just throws a TypeError immediately". So |
Ah! In that case, the answer is no: all web platform classes want to use the same delegating-to-[[Call]] behavior. In "non-constructible" cases (e.g. I can see now that my OP wording was confusing. It's reflecting the history of that whatwg/webidl#698 , and not super-helpful as an introduction of the problem for this issue tracker. (Briefly: all Web IDL "non-constructible classes" have always been specified as built-in functions whose function steps are to immediately throw a TypeError. whatwg/webidl#698 was debating whether attempting to construct them should throw a TypeError because they have no [[Construct]] at all, or should throw a TypeError because they have a [[Construct]] that delegates to their [[Call]]. This is not observable when doing |
Thanks, that's very helpful! |
@domenic its not clear to me in that issue why to prefer the delegation version; can you elaborate or link me to the relevant comments? |
I was actually saying "Don't bother going in that direction, it's a dead end."
My guess would be that other specs don't mandate the implementation strategy for built-ins.
Presumably you don't mean that the new AO itself would invoke the function's
I'm not sure that's worth making into an operation, but I guess it's an option. |
Yes, that's what I meant.
This is indeed true, but I think "Set F.[[Consntruct]] to the definition specified in 9.3.2" could use editorial improvement. My understanding is that the steps passed to https://tc39.es/ecma262/#sec-createbuiltinfunction are slotted in to step 7 of 9.3.1 via step 5 of 9.3.3. This new AO I'm envisioning would make that explicit, hopefully. |
Step 7 of 9.3.1 sets In
(And if applicable, all that similarly for
(So this new AO would handle You could easily make the selection between 9.2.1 and 9.3.1 explicit, similar to the pseudocode for choosing between 9.2.2 and 9.3.2 I gave above. But note that @ExE-Boss proposed something like that in PR #2115, and got some pushback from @bakkot. As for the magic of how |
What's the latest here? It looks like maybe MakeConstructor can be used for this now? |
Hmm, I guess not, since MakeConstructor sets [[Construct]] to 10.2.2, but we'd instead want to set it to 10.3.2 I believe. |
In whatwg/webidl#698, we've come to the conclusion that all web platform classes should have a [[Construct]], even if it just throws a TypeError immediately. However, we're unsure how to express that in spec language.
Currently (in create an interface object step 4) we do
However this doesn't appear to give us [[Construct]] automatically.
For the ES spec itself, it seems things are done fairly implicitly: https://tc39.es/ecma262/#sec-built-in-function-objects says
then later
which manifests in individual built-in functions via clauses like "the Number constructor" versus "the isFinite function".
For web specifications, how would you suggest specifying our counterpart? Especially given our more-imperative realm creation routine. My current guess is to add a step like
although this feels a bit informal and wishy-washy. (The fact that we have to explain it with a note, instead of e.g. a hyperlink, is a sign of my discomfort.) Would that be the best approach?
The text was updated successfully, but these errors were encountered: