Proposal: Splitting the "Standard Library" from the EcmaScript spec
concavelenz at gmail.com
Thu Jul 28 17:02:08 UTC 2016
A fair amount of text in the EcmaScript spec is spent on defining the
EcmaScript standard classes and methods. This has the side-effect of doing
- encouraging standard classes/methods to have special behavior
- discouraging creating appropriate "building blocks"
How differently would EcmaScript have been defined if Map, WeakMap,
Promise, etc were only defined in terms of a "core" language. Would we
have a standard identity hash code? A concept of time?
Many of the existing Array.prototype methods, etc could be moved to
"Library" project that could be defined in terms of an implementation
rather than step-by-step spec language.
To be clear, I'm not proposing a different delivery mechanism (aka "import
foo from std") but simply a change to the evolutionary process to encourage
a clean separation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss