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

OK, I see now that the algorithms define many things in an ECMAScripty way which has more details. I was thrown by the fact that a section labeled "Class Definition" was in fact not a normative definition, my bad.

I hesitate to add more, because I've been told this topic is a "can of worms", but some additional thoughts:

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. Maybe this can be inferred from "look at the ECMAScript spec" but at a glance I was not sure how.

Web IDL also ensures certain behaviors are consistent. Many browser-hosted implementations of Streams will likely use some form of IDL definition and bindings that are meant to be consistent with Web IDL behaviors. At least Blink and WebKit appear to do it that way. It's somewhat inconvenient that browsers have to each reverse-engineer the IDL from non-IDL definitions. Also, while it may be that what the spec requires happens to 100% align with how the obvious IDL translation would behave, if it doesn't, then it's likely implementations will be wrong. At the very least it's not immediately obvious that this is the case. 

Blink and WebKit seem to represent ReadableStream's cancel method like this in IDL (respectively): 
    [CallWith=ScriptState] Promise<void> cancel(optional any reason);
    [NotEnumerable] Promise<any> cancel(optional any reason);

Is either of these correct? I dunno. They both say the reason argument is optional but that is not clear from the spec. The algorithm for the cancel method in the spec does not say it is optional. Maybe it's implicit? But I think other parameters are not optional. I'm not sure how the promise type was determined but it's concerning that they don't agree. I think that difference may result in an observable behavior difference. Also not sure why WebKit decided this method should not be Enumerable.

This is an example of the kinds of details that are left unclear by the current spec style.



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