Proposal: Splitting the "Standard Library" from the EcmaScript spec

[Kris Siegel]

I love this idea. I was originally hoping to champion a whole slew of
additions to the JavaScript Standard Library because I'd really love for a
set of standard ways to do much of what we use private APIs today (lack of
time to follow up on my original thread).

I'm not sure how it works out logistically though with ECMA. But a
separation at least makes sense to me (especially if we start adding a lot
to the standard library which I know many are against but like Python I
think it would be a huge boon to the JavaScript community).

I don't think import foo from std is the worst idea either but that would
be breaking unless we put it under "use stricter" or something similar.

On Jul 28, 2016 10:02 AM, "John Lenz" <concavelenz at gmail.com> wrote:

> 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
> two things:
>
>   - 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.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160728/40d28d45/attachment.html>