Make things like Reflect an import instead of a global?

/#!/JoePea joe at trusktr.io
Sat Oct 8 23:32:48 UTC 2016


Hehe, well, making everything a global is one way to design it. ;} Can't
wait for modules to be native!

*/#!/*JoePea

On Fri, Sep 23, 2016 at 2:29 AM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> 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/20161008/9d8cbcef/attachment-0001.html>


More information about the es-discuss mailing list