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

domenic requested changes on this pull request.

I think this could be finished without much extra work; in particular there was talk of blocking this on defining `this` but I don't think that's necessary. It'd be really exciting to see this land and get this aspect of object creation and branding fully defined.

>  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

```suggestion
     To <dfn export lt="new|create|create a new|create an object implementing|create an object implementing the interface">create an object implementing the interface</dfn> |interface|, with optional
```

>  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

```suggestion
     internal slots |slots| and `new.target` value |newTarget|, for an interface which is not
```

>  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%")

Relatedly, I can never think of a case when a web platform specification would provide a newTarget value to this algorithm. I guess from the definition of a Web IDL constructor, but that's rare. Can we create a wrapper that does not allow passing new.target?

>  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%")
+    1. Otherwise,
+        1. Let |realm| be the [=relevant Realm=] of the |this| value that led to the execution of this algorithm.

I think |realm| should be a parameter, which callers are allowed to omit if they are in a context that contains such a this value.

>  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%")
+    1. Otherwise,
+        1. Let |realm| be the [=relevant Realm=] of the |this| value that led to the execution of this algorithm.

We seem to use `<emu-val>this</emu-val> value` through the rest of the spec.

>  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|, 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. Let |proto| be the [=interface prototype object=] of |interface|.
+    1. Let |instance| be [$ObjectCreate$](|proto|, |slots|).
+    1. Set |instance|.\[[PrimaryInterface]] to |interface|.
+    1. Let |realm| be the current [=Realm=].

Too much cryptic boilerplate. As I mentioned above, I think the usage should be one of

> Create a new X object

or, if there is no this value

> Create a new X object in the relevant realm of abc

>  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%")
+    1. Otherwise,
+        1. Let |realm| be the [=relevant Realm=] of the |this| value that led to the execution of this algorithm.
+        1. Let |proto| be the [=interface prototype object=] of |interface| in |realm|.
+        1. Let |instance| be [$ObjectCreate$](|proto|, |slots|).
+    1. Set |instance|.\[[PrimaryInterface]] to |interface|.
+    1. Let |realm| be the current [=Realm=].

The mismatch where you use relevant realm of this above, and current realm here, seems bad.

>  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

I would omit allowing passing internal slots until or unless we figure out a story for #258. It'd be bad if we had a few specifications start using "create a new X with slots [[Y]], [[Z]], [[W]]" and then later told them all to transition to putting their slot declarations in their IDL blocks, or similar.

-- 
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#pullrequestreview-187544768