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

littledan 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|, 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=].

It seems like we have two modes where this algorithm will be called:
- Passing a new.target value (from all constructors)
- Somehow indicating a realm. I made this PR vaguely refer to the relevant realm of the relevant *this* value, but I'm not sure how we should formalize this or let folks pass in their own *this*/realm.

Could we say that, if you don't have a relevant *this* value, then you should explicitly pass in the new.target value? Specs could use wording like this:

> Create a new object implementing the XYZ interface, with new.target of the interface prototype object of the relevant realm of abc.

Or is that too much cryptic boilerplate?

-- 
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_r241095196