Make things like Reflect an import instead of a global?

Isiah Meadows isiahmeadows at gmail.com
Fri Sep 23 09:29:50 UTC 2016


I don't believe there's a formal proposal yet, but there definitely should
be. It's been discussed frequently for years by the standards leaders; it's
just that we're 1. still waiting on a loader spec for modules to complete
(the WHATWG spec is still a work in progress, with quite a bit of recent
flux), and 2. a standard library isn't exactly a trivial thing to design.

On Tue, Sep 20, 2016, 01:52 Kris Siegel <krissiegel at gmail.com> wrote:

> Are there any proposals regarding built-in module mechanisms or at least
> someone to champion it during ECMA meetings? Similar to Joe's point if this
> isn't a blocking issue then releasing item after item into the global scope
> means they are stuck there forever (unless something like "use stricter";
> or whatever other silliness is added to gate the changes). This seems to me
> like it shouldn't be that hard to do if someone is championing / proposing.
>
> On Tue, Aug 23, 2016 at 8:26 PM, /#!/JoePea <joe at trusktr.io> wrote:
>
>> True, I understand we can't practically do it at the moment since native
>> module systems aren't implemented yet. I guess I am simply expressing that
>> it would be awesome and that I can't wait for that to happen sooner than
>> later so that new awesome features/tools can be modules instead of globals.
>>
>> The part that gives me a tiny bit of despair is that if something is
>> released as a global, then it will stay that way essentially forever, for
>> backwards compatibility. That is the part that makes me feel a tiny bit bad
>> inside considering that the amazing language for modules is already defined.
>>
>> */#!/*JoePea
>>
>> On Tue, Aug 16, 2016 at 9:49 PM, Jordan Harband <ljharb at gmail.com> wrote:
>>
>>> We don't yet have a mechanism for built-in modules, and that's not going
>>> to be an obstacle for continuing to improve the language.
>>>
>>> As soon as a viable mechanism and precedent exists for that, new things
>>> very well might only be added via that mechanism, rather than solely by
>>> adding new global things.
>>>
>>> On Tue, Aug 16, 2016 at 6:52 PM, /#!/JoePea <joe at trusktr.io> wrote:
>>>
>>>> Seems like when the ES6 Modules became official that it would be a good
>>>> idea to *not* define more globals in the language, and instead spec things
>>>> to be modules, f.e. something like:
>>>>
>>>> ```js
>>>> import {apply} from 'Reflect'
>>>> // insead of
>>>> const {apply} = window.Reflect
>>>> ```
>>>>
>>>> This would also be a pattern for programs that use the JS engine to
>>>> follow:
>>>>
>>>> ```js
>>>> import {define} from 'CustomElements' // in browsers
>>>> // instead of
>>>> const {define} = window.customElements
>>>> ```
>>>>
>>>> Maybe a symbol would be needed for any modules that are native?
>>>>
>>>> ```js
>>>> import {define} from '#CustomElements' // # means native module
>>>> ```
>>>>
>>>> */#!/*JoePea
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> 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/20160923/c2ce53a9/attachment-0001.html>


More information about the es-discuss mailing list