Re: [heycam/webidl] Add an algorithm to create a platform object. (#635)

littledan commented on this pull request.



>  
     1.  Assert: |interface| is [=exposed=] in |realm|.
+    1.  Let prototype be the [=interface prototype object=] for |interface| in
+        |realm|.
+    1.  If |newTarget| is provided, then:
+        1.  Issue: If we just pass {{NewTarget}} through in a constructor, would this not
+            always be defined (sometimes to the [=interface object=] itself)?
+        1.  Let |newTargetPrototype| be [=?=] [$Get$](|newTarget|, "prototype").

The logic here is a bit different from the JS spec, which is based on [OrdinaryCreateFromConstructor](https://tc39.github.io/ecma262/#sec-ordinarycreatefromconstructor).

Actually, it seems like we've opened up here a whole world of divergence between JS and the Web, as well as between browsers. Consider this test case:

```js
function foo() { }
function bar() { } bar.prototype = 1;

console.log(`
  ${ Reflect.construct(URL, ["file:///foo"], foo).constructor.name }
  ${ Reflect.construct(URL, ["file:///foo"], bar).constructor.name }
  ${ Reflect.construct(Uint8Array, [1], foo).constructor.name }
  ${ Reflect.construct(Uint8Array, [1], bar).constructor.name }
`);
```

WebKit results:

```
  URL
  URL
  foo
  Uint8Array
```

Chromium results:

```
  foo
  Object
  foo
  Uint8Array
```

Gecko results:

```
  foo
  URL
  foo
  Uint8Array
```

The Gecko results have the closest analogy to JavaScript here--they are as if we're following the OrdinaryCreateFromConstructor algorithm, with all of the platform interfaces included in the fallback list. If Chromium and WebKit folks are in favor of it, I'd suggest adopting these semantics.

-- 
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/635#pullrequestreview-201063925