Re: [heycam/webidl] Considering factoring WebIDL to allow use from the ECMAScript specification (#486)

> I theorize that the subset of WebIDL we'd want for 262 is small enough relative to all of WebIDL that the benefits of @littledan's proposed layering will be pretty nice in terms of clarity and understandability. It also serves as a nice way to document the subset of WebIDL in use.

I looked into this, and it seems the opposite is true. At a quick glance, ES would use way more of Web IDL than URL does, especially given the proposals to introduce new features specifically for ES.

Things not needed by ES by my count are:

- General concepts (from section 2):
  - Named properties (legacy)
  - Named constructors (legacy)
  - Maplike/setlike
  - Probably a couple numeric types (most will be used by typed arrays though)
  - Maybe ByteString and USVString (402 and the very old string stdlib functions might use these; unsure)
  - Frozen array types
- Further ES binding details (from section 3):
  - A number of extended attributes, but mostly the ones we consider legacy already (https://github.com/heycam/webidl/issues/350)
  - Maybe the security checks? Not sure, especially SpiderMonkey vs. others.
  - Legacy callback interface objects
- Common definition types
  - DOMException
  - DOMTimeStamp (although it's just a typedef)

This enumeration indicates to me that perhaps one resolution that would help people understand how Web IDL is a good base layer below ECMAScript is by more aggressively renaming legacy things to legacy, as we've intended for some time, and possibly moving them to an appendix, if people think that would help. That kind of separation, which is already aligned with Web IDL's goals, feels better than these complex layering diagrams---which don't account for how ES would be a peer to URL and friends, in how they depend on Web IDL.

-- 
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/issues/486#issuecomment-349715352

Received on Wednesday, 6 December 2017 18:48:33 UTC