Re: [whatwg/streams] Exact normative requirements for interface definitions are unclear (#732)

> I still think many ECMAScripty details are not fully spelled out. For example, Web IDL spells out what type conversions happen to parameters or values assigned to, how constructors appear on the global object, the full property descriptors of every property, etc. 

Like in the ES spec, all conversions are spelled out explicitly here (e.g. https://streams.spec.whatwg.org/#rs-pipe-to steps 1-3). The global object properties are in https://streams.spec.whatwg.org/#globals.

> Blink and WebKit seem to represent ReadableStream's cancel method like this in IDL (respectively):

Where do you find this IDL for Blink? Blink implements its Readable Stream implementation the same way it does its other ES-style builtins: https://cs.chromium.org/webrtc/src/third_party/WebKit/Source/core/streams/ReadableStream.js

I agree that the WebKit engineers seem to have tried to reverse-engineer some Web IDL from the spec's normative text. I'm not sure why they did that; perhaps they found benefits to Web IDL in their pipeline that outweighed the cost of coming up with it themselves (and using nonstandardized extended attributes like [NotEnumerable] to compensate for the IDL/ES mismatch).

> Also not sure why WebKit decided this method should not be Enumerable.

(It is in Blink also) This is per https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects which says 

> Every other data property described in clauses 18 through 26 and in Annex B.2 has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } unless otherwise specified.

---

Stepping back a bit, I acknowledge that the exact pointers to https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects are not super-clear. And that it's definitely unusual for people used to implementing web specs to understand the ES structure, e.g. the somewhat-hidden "Global Properties" section. The non-normative class definition is certainly misleading and confusing, if read by implementers; it is intended for web developers.

I do believe all details are clear in theory, even if there are practical difficulties in getting to that clarity that I would like to address.

In the end Web IDL might have been a better choice. At the time this spec was first created, it was envisioned as a language-level primitive like promises. It still is envisioned and specced that way, despite it being under WHATWG instead of TC39. But people seem to expect that only TC39 produces specs in the ES style. We didn't realize this expectation would be so strong when creating it.

Now we're in a bit of a tough spot. The spec currently mandates many small things that cannot be expressed in IDL, such as non-enumerable methods, data properties (on the two queuing strategy classes), and no brand-checking (on the queuing strategies and on ReadableStream's pipeThrough method). Additionally, at least two of the open-source implementations (Blink and Gecko) are done without IDL, using the same framework as their JS engine does for other language-level primitives. We could upend all of that; I don't believe the compatibility impact would be too large, as most developers won't be writing code that depends on e.g. countQueuingStrategy.highWaterMark being a data property. But I think it would be a net negative. It would help implementers that use IDL (1/3 open source engines), but make the actual developer-facing semantics slightly less good in various small ways.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/732#issuecomment-293458890