-
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 a callback constructor type #701
Comments
It has the drawback of adding a new reserved word to IDL and hence needing to munge various places that want "identifier or anything that looks like one" in the grammar, but we should be able to just find all of those by searching the grammar for "interface", by analogy with |
|
Note however we may want to consider defining this feature more holistically. For example custom elements, and I believe worklet APIs, want to not only construct the constructor, but pull properties off of it (e.g. step 10 of https://html.spec.whatwg.org/multipage/custom-elements.html#dom-customelementregistry-define). That could lead to different syntax. |
I did consider That said the audio worklet case just seems to want to construct the thing. I agree we should look at the other possible consumers to see what they want. |
Looks like Gecko already got an implementation of this in https://bugzilla.mozilla.org/show_bug.cgi?id=1542932 |
Note that at the moment that does not have the semantics proposed above. In particular we do not verify that the passed-in function is a constructor in the binding layer. From the point of view of observable binding behavior it's just an alias for |
What about something like this:
Concept is rough, and it is technically larger than everything else that's been proposed here, but it aligns pretty well conceptually with WebIDL's current processing model and shouldn't require more than mechanical changes from how it's currently consumed. It also is intended to satisfy the needs of both Houdini, custom elements, and worklets. |
What are the actual semantics of that proposal? |
@bzbarsky So here's what I was thinking:
I was trying to avoid over-specifying here, and I probably left a few holes here by accident. But hopefully this clarifies what I'm suggesting. The overarching goal is to have a solution that solves the needs at hand flexibly while still being intuitively WebIDL. (And implementations can just desugar, abstract, and track a few new invariants - it's not a radical change to implement.) |
In particular something we verify to be a callback that also passes https://tc39.github.io/ecma262/#sec-isconstructor.
This could be used to remove the first step of https://html.spec.whatwg.org/multipage/custom-elements.html#dom-customelementregistry-define.
It would also help WebAudio/web-audio-api#1843 and other Worklet APIs dealing with constructors.
Invoking the constructor would go through https://heycam.github.io/webidl/#construct-a-callback-function though that can be tightened up a bit by no longer having to check that it's a constructor.
The text was updated successfully, but these errors were encountered: