es7-membrane: A new ECMAScript 2016 Membrane implementation
looks like you missed the part of the chapter that convered this :)
exploringjs.com/es6/ch_modules.html#_imports-and-exports-must-be-at-the-top-level
but the tl;dr is imports are statically resolved before runtime and so must be at the top level outside of any sort of block or function. In other words if there is an error when it comes to importing something the code won't run so a try catch is unneeded.
looks like you missed the part of the chapter that convered this :) http://exploringjs.com/es6/ch_modules.html#_imports-and-exports-must-be-at-the-top-level but the tl;dr is imports are statically resolved before runtime and so must be at the top level outside of any sort of block or function. In other words if there is an error when it comes to importing something the code won't run so a try catch is unneeded. On Tue, Aug 23, 2016 at 6:54 AM Alex Vincent <ajvincent at gmail.com> wrote: > I have a new ECMAScript membrane implementation [1], which I will maintain > and use in a professional capacity, and which I’m looking for lots of help > with in the form of code reviews and API design advice. > > I wrote a lengthier post on my weblog [2], with more details of what I > hope to get out of it. From this group, I'm hoping to get some API design > advice, and suggestions on how to make it even more ECMAScript-friendly and > follow the rules of ES6 modules. > > Side note, specifically for this group: After reading Dr. Rauschmeyer's > chapter on ES6 modules [3], I tried writing the following: > try { > import ... > } > catch (e) { > // do something else > } > > But that resulted in a syntax error for import not being the first line of > the script. I really wonder why it's illegal to wrap the import statement > in a try block... > > [1] https://github.com/ajvincent/es7-membrane > [2] https://alexvincent.us/blog/?p=908 > [3] http://exploringjs.com/es6/ch_modules.html > > Thank you for both your time and your good work on the ES6 specification > and implementations! > > > > Alex Vincent > Hayward, CA > > -- > "The first step in confirming there is a bug in someone else's work is > confirming there are no bugs in your own." > -- Alexander J. Vincent, June 30, 2001 > _______________________________________________ > 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/c262c5df/attachment.html>
Sidenote: Ben Newman's Reify implements experimental deferred (non-top-level) imports in which case you can wrap imports in a try-catch. It's been really nice in practice (I've been taking advantage of it in Meteor, which uses Reify).
Sidenote: Ben Newman's [Reify](https://github.com/benjamn/reify) implements experimental deferred (non-top-level) imports in which case you *can* wrap imports in a try-catch. It's been really nice in practice (I've been taking advantage of it in Meteor, which uses Reify). */#!/*JoePea On Tue, Aug 23, 2016 at 2:17 AM, Calvin Metcalf <calvin.metcalf at gmail.com> wrote: > looks like you missed the part of the chapter that convered this :) > > http://exploringjs.com/es6/ch_modules.html#_imports-and- > exports-must-be-at-the-top-level > > but the tl;dr is imports are statically resolved before runtime and so > must be at the top level outside of any sort of block or function. In > other words if there is an error when it comes to importing something the > code won't run so a try catch is unneeded. > > > On Tue, Aug 23, 2016 at 6:54 AM Alex Vincent <ajvincent at gmail.com> wrote: > >> I have a new ECMAScript membrane implementation [1], which I will >> maintain and use in a professional capacity, and which I’m looking for lots >> of help with in the form of code reviews and API design advice. >> >> I wrote a lengthier post on my weblog [2], with more details of what I >> hope to get out of it. From this group, I'm hoping to get some API design >> advice, and suggestions on how to make it even more ECMAScript-friendly and >> follow the rules of ES6 modules. >> >> Side note, specifically for this group: After reading Dr. Rauschmeyer's >> chapter on ES6 modules [3], I tried writing the following: >> try { >> import ... >> } >> catch (e) { >> // do something else >> } >> >> But that resulted in a syntax error for import not being the first line >> of the script. I really wonder why it's illegal to wrap the import >> statement in a try block... >> >> [1] https://github.com/ajvincent/es7-membrane >> [2] https://alexvincent.us/blog/?p=908 >> [3] http://exploringjs.com/es6/ch_modules.html >> >> Thank you for both your time and your good work on the ES6 specification >> and implementations! >> >> >> >> Alex Vincent >> Hayward, CA >> >> -- >> "The first step in confirming there is a bug in someone else's work is >> confirming there are no bugs in your own." >> -- Alexander J. Vincent, June 30, 2001 >> _______________________________________________ >> 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/20160823/d19f3465/attachment.html>
More importantly, Ben Newman is championing a proposal for nested imports: tc39/ecma262#646
More importantly, Ben Newman is championing a proposal for nested imports: https://github.com/tc39/ecma262/pull/646 - Rick On Tue, Aug 23, 2016 at 11:30 PM /#!/JoePea <joe at trusktr.io> wrote: > Sidenote: Ben Newman's [Reify](https://github.com/benjamn/reify) > implements experimental deferred (non-top-level) imports in which case you > *can* wrap imports in a try-catch. It's been really nice in practice (I've > been taking advantage of it in Meteor, which uses Reify). > > */#!/*JoePea > > On Tue, Aug 23, 2016 at 2:17 AM, Calvin Metcalf <calvin.metcalf at gmail.com> > wrote: > >> looks like you missed the part of the chapter that convered this :) >> >> >> http://exploringjs.com/es6/ch_modules.html#_imports-and-exports-must-be-at-the-top-level >> >> but the tl;dr is imports are statically resolved before runtime and so >> must be at the top level outside of any sort of block or function. In >> other words if there is an error when it comes to importing something the >> code won't run so a try catch is unneeded. >> >> >> On Tue, Aug 23, 2016 at 6:54 AM Alex Vincent <ajvincent at gmail.com> wrote: >> >>> I have a new ECMAScript membrane implementation [1], which I will >>> maintain and use in a professional capacity, and which I’m looking for lots >>> of help with in the form of code reviews and API design advice. >>> >>> I wrote a lengthier post on my weblog [2], with more details of what I >>> hope to get out of it. From this group, I'm hoping to get some API design >>> advice, and suggestions on how to make it even more ECMAScript-friendly and >>> follow the rules of ES6 modules. >>> >>> Side note, specifically for this group: After reading Dr. Rauschmeyer's >>> chapter on ES6 modules [3], I tried writing the following: >>> try { >>> import ... >>> } >>> catch (e) { >>> // do something else >>> } >>> >>> But that resulted in a syntax error for import not being the first line >>> of the script. I really wonder why it's illegal to wrap the import >>> statement in a try block... >>> >>> [1] https://github.com/ajvincent/es7-membrane >>> [2] https://alexvincent.us/blog/?p=908 >>> [3] http://exploringjs.com/es6/ch_modules.html >>> >>> Thank you for both your time and your good work on the ES6 specification >>> and implementations! >>> >>> >>> >>> Alex Vincent >>> Hayward, CA >>> >>> -- >>> "The first step in confirming there is a bug in someone else's work is >>> confirming there are no bugs in your own." >>> -- Alexander J. Vincent, June 30, 2001 >>> _______________________________________________ >>> 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/20160824/d5618757/attachment-0001.html>
A follow-up to my earlier posts: es7-membrane has reached version 0.7, which features a practical whitelist capability, multiple object graphs, and support for ES6 symbols as the "names" of object graphs.
I'd still like to find some volunteer contributors. Also, a colleague on the SES task force suggested the es7-membrane project's tests might be ported to make a good integration test for test-262 (as opposed to unit tests)...
A follow-up to my earlier posts: es7-membrane has reached version 0.7, which features a practical whitelist capability, multiple object graphs, and support for ES6 symbols as the "names" of object graphs. I'd still like to find some volunteer contributors. Also, a colleague on the SES task force suggested the es7-membrane project's tests might be ported to make a good integration test for test-262 (as opposed to unit tests)... https://alexvincent.us/blog/?p=922 https://github.com/ajvincent/es7-membrane On Mon, Aug 22, 2016 at 9:53 PM, Alex Vincent <ajvincent at gmail.com> wrote: > I have a new ECMAScript membrane implementation [1], which I will maintain > and use in a professional capacity, and which I’m looking for lots of help > with in the form of code reviews and API design advice. > > I wrote a lengthier post on my weblog [2], with more details of what I > hope to get out of it. From this group, I'm hoping to get some API design > advice, and suggestions on how to make it even more ECMAScript-friendly and > follow the rules of ES6 modules. > > Side note, specifically for this group: After reading Dr. Rauschmeyer's > chapter on ES6 modules [3], I tried writing the following: > try { > import ... > } > catch (e) { > // do something else > } > > But that resulted in a syntax error for import not being the first line of > the script. I really wonder why it's illegal to wrap the import statement > in a try block... > > [1] https://github.com/ajvincent/es7-membrane > [2] https://alexvincent.us/blog/?p=908 > [3] http://exploringjs.com/es6/ch_modules.html > > Thank you for both your time and your good work on the ES6 specification > and implementations! > > > > Alex Vincent > Hayward, CA > > -- > "The first step in confirming there is a bug in someone else's work is > confirming there are no bugs in your own." > -- Alexander J. Vincent, June 30, 2001 > -- "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- Alexander J. Vincent, June 30, 2001 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170318/5a632bab/attachment.html>
I have a new ECMAScript membrane implementation, which I will maintain and use in a professional capacity, and which I’m looking for lots of help with in the form of code reviews and API design advice.
I wrote a lengthier post on my weblog, with more details of what I hope to get out of it. From this group, I'm hoping to get some API design advice, and suggestions on how to make it even more ECMAScript-friendly and follow the rules of ES6 modules.
Side note, specifically for this group: After reading Dr. Rauschmeyer's chapter on ES6 modules, I tried writing the following:
try { import ... } catch (e) { // do something else }
But that resulted in a syntax error for import not being the first line of the script. I really wonder why it's illegal to wrap the import statement in a try block...
Thank you for both your time and your good work on the ES6 specification and implementations!