Make things like Reflect an import instead of a global?
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.
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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160816/7afa19c2/attachment.html>
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.
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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160823/8319ee9e/attachment.html>
FYI, there is a discussion on built-in modules here: tc39/ecma262#395
FYI, there is a discussion on built-in modules here: https://github.com/tc39/ecma262/issues/395 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160904/79dd55fc/attachment.html>
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.
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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160919/f1627007/attachment.html>
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.
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>
Hehe, well, making everything a global is one way to design it. ;} Can't wait for modules to be native!
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>
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:
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:
import {define} from 'CustomElements' // in browsers // instead of const {define} = window.customElements
Maybe a symbol would be needed for any modules that are native?
import {define} from '#CustomElements' // # means native module