es7-membrane: A new ECMAScript 2016 Membrane implementation

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

es7-membrane: A new ECMAScript 2016 Membrane implementation

Alex Vincent
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...
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: es7-membrane: A new ECMAScript 2016 Membrane implementation

Calvin Metcalf
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 <[hidden email]> 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...
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: es7-membrane: A new ECMAScript 2016 Membrane implementation

/#!/JoePea
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 <[hidden email]> 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 <[hidden email]> 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...
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: es7-membrane: A new ECMAScript 2016 Membrane implementation

Rick Waldron
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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...
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: es7-membrane: A new ECMAScript 2016 Membrane implementation

Alex Vincent
In reply to this post by Alex Vincent
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)...

On Mon, Aug 22, 2016 at 9:53 PM, Alex Vincent <[hidden email]> 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...
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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Loading...