-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editorial: Consider reading all options first, then doing things with them #132
Comments
I'm concern that we don't reference IDL from 262. It is true that we can follow this principle to accomodate WebIDL better, and avoid simple mistakes, I will try to enforce that from now on every pull request. Additionally, any pull request that align with this organization will be welcome :) |
What do you mean by this? Why wouldn't you want such a reference? |
@bterlson Do you expect to be proposing any kind of JSIDL? This could be a part of it. |
@littledan it's pretty far down my priority stack but I believe JSIDL is key technology we TC39ers should be investigating. Anything I can do to help get this effort off the ground? |
@bterlson Well, do you plan to present on it any time soon, or do you have any more concrete things towards design docs? Or any more ideas you could sketch out here? |
@littledan no plans, but I could help work on one. No design docs, but I can write down the various bits I covered in the meeting a while back. Basic idea is an WebIDL subset with possibly minor extensions. |
@bterlson @littledan What is the current status of this issue? Is there a WebIDL document we can now review? |
It seems like a worthy improvement to 402, if web compatible, unrelated to whether any IDL is used. |
@littledan your proposal here is exactly what I think Temporal should be doing with Calendar/TimeZone objects, if they're spiritually intended to be options bags. |
With WebIDL Dictionaries, the process is
For ECMA 402, the process is a little more intertwined. Reading out of the options object is interspersed with doing calculations with the values. This pattern of writing to the spec leads to funny artifacts like #131 .
Maybe we should organize the Intl spec more similar to WebIDL, and do the conversion separately.
To go a step further, maybe the ideal would be to normatively reference WebIDL, so that we achieve complete consistency with many other API definitions. Note that being defined in WebIDL doesn't mean that an API is shipped only to the web. For example, Node.js has a module for the URL spec, despite being specified with WebIDL.
The text was updated successfully, but these errors were encountered: