-
Notifications
You must be signed in to change notification settings - Fork 162
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
Define "usual constructor steps" #797
Conversation
This is for use in [HTMLConstructor] in whatwg/html#4915.
I'm not a big fan of this approach, personally; I think it'd be better to have something like
Any reason you're referring to the interface object, in particular? |
Sounds like my second option, right? Can do.
Nope, interface makes sense too. |
@Ms2ger I pushed a new approach, but I feel like there should be some warning text talking about how these steps are not general-purpose and are only used in special scenarios. Would you be able to help draft such text? I'm having some trouble doing so myself. |
An interface may have <dfn export>overridden constructor steps</dfn>, which can | ||
change the behavior of the [=interface object=] when called or constructed. By | ||
default interfaces do not have such steps. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add a warning like we have a few already for legacy features, saying something like
In general, constructors are described by defining a [=constructor operation=] and its behavior.
The [=overridden constructor steps=] are used only for more complicated situations.
Editors who wish to use this feature are strongly advised to discuss this by filing an issue before proceeding.
<div algorithm> | ||
|
||
The [=interface object=] for a given [=interface=] |I| | ||
with [=identifier=] |id| and in [=Realm=] |realm| | ||
is <dfn lt="create an interface object">created</dfn> as follows: | ||
|
||
1. Let |steps| be the following steps: | ||
1. Let |steps| be |I|'s [=overriden constructor steps=] if they exist, or | ||
the following steps otherwise: | ||
1. If |I| was not declared with a [=constructor operation=], | ||
then [=ECMAScript/throw=] a {{ECMAScript/TypeError}}. | ||
1. If {{NewTarget}} is <emu-val>undefined</emu-val>, then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we keep the first two steps, even when overriding the rest of the algorithm?
Maybe also the last four steps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that would work for [HTMLConstructor], although it feels cleaner to just have a general primitive that replaces the whole thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll keep it like this for now, but we can refactor later if you think it's much better.
This is for use in [HTMLConstructor] in whatwg/html#4915.
There are alternative approaches and wordings that might be better, e.g.
But I thought I'd start here to get the ball rolling, as it's the first thing that occurred to me. Happy to tweak as desired.
Preview | Diff