Re: [heycam/webidl] Define "implements" checks using internal slots (#595)

domenic commented on this pull request.



>  Every [=platform object=] is associated with a global environment, just
 as the [=initial objects=] are.
 It is the responsibility of specifications using Web IDL to state
 which global environment (or, by proxy, which global object) each platform
 object is associated with.
 
+<div algorithm>
+    To <dfn>create an object implementing the interface</dfn> |interface|, with optional
+    intenal slots |slots| and |new.target| value |newTarget|, for an interface which is not
+    declared with the [{{Global}}] [=extended attribute=], perform the following steps:
+
+    1. If |slots| is provided, append \[[PrimaryInterface]] to |slots|.
+    1. Otherwise, let |slots| be &laquo; \[[PrimaryInterface]] &raquo;.
+    1. If |NewTarget| is provided, let |instance| be ? [$OrdinaryCreateFromConstructor$](|newTarget|, "%ObjectPrototype%")

Hmm yeah it's true that currently most web platform spec constructors are done "return override" style, i.e. they have a step that says "create a new X object" which Web IDL calls as part of https://heycam.github.io/webidl/#create-an-interface-object. Maybe we need to rethink that. I can see either "create a new instance of the interface being constructed" (which will do the right new.target thing for you) or making it implicit, by e.g. Web IDL allocating "this" for you before calling the constructor steps.

I think we should figure out which direction we want before landing this, but switching over specs to use it can be done as part of the larger project to get specs to use these new dfns, so it's OK if we create something novel that doesn't mesh with existing practice. As long as we're aligned on the right direction.

-- 
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/pull/595#discussion_r243703392