Re: Dynamic Modules Questions
Le 06/03/2013 23:31, Sam Tobin-Hochstadt a écrit : On Wed, Mar 6, 2013 at 9:46 AM, Kevin Smith khs4...@gmail.com wrote: (Referencing the module loaders proposal at http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders) 1) Loaders have a strict flag which indicates whether code evaluated in the Loader's context should be implicitly strict. If modules themselves are implicitly strict, is this flag superfluous? myLoader.eval(someJS) is just like regular `eval`, and also loaders handle `eval` called from inside them. So no, the flag isn't superfluous. I fail to understand the benefit of forcing the mode of the loaded code. There is a risk to break the loaded code by forcing a mode it might not have been written for. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Dynamic Modules Questions
On Mar 6, 2013 10:04 PM, Kevin Smith khs4...@gmail.com wrote: 3) There doesn't appear to be a way to provide a dynamically created module instance (created via the Module constructor) as the result of the fetch hook. My thought is that such a feature might be useful for implementing dynamically linked binary add-on modules in server environments. This is a good thought, and one we've considered. Note that you can simply dynamically add the module using `System.set` during the fetch hook. This would imply that the result of the fetch hook is ignored if the module has been installed in the module instance table before the hook callbacks are executed. True? This is the same for all the loader hooks, in fact. Also, what is `System` exactly? The base loader or something else? Yes, System is the name we've chosen for the default loader. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Dynamic Modules Questions
On Mar 7, 2013 4:53 AM, David Bruant bruan...@gmail.com wrote: Le 06/03/2013 23:31, Sam Tobin-Hochstadt a écrit : On Wed, Mar 6, 2013 at 9:46 AM, Kevin Smith khs4...@gmail.com wrote: (Referencing the module loaders proposal at http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders) 1) Loaders have a strict flag which indicates whether code evaluated in the Loader's context should be implicitly strict. If modules themselves are implicitly strict, is this flag superfluous? myLoader.eval(someJS) is just like regular `eval`, and also loaders handle `eval` called from inside them. So no, the flag isn't superfluous. I fail to understand the benefit of forcing the mode of the loaded code. There is a risk to break the loaded code by forcing a mode it might not have been written for. Then you probably won't want to use this option when constructing loaders. Others, I'm sure, feel differently. Sam ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Dynamic Modules Questions
Le 07/03/2013 13:19, Sam Tobin-Hochstadt a écrit : On Mar 7, 2013 4:53 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 06/03/2013 23:31, Sam Tobin-Hochstadt a écrit : On Wed, Mar 6, 2013 at 9:46 AM, Kevin Smith khs4...@gmail.com mailto:khs4...@gmail.com wrote: (Referencing the module loaders proposal at http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders) 1) Loaders have a strict flag which indicates whether code evaluated in the Loader's context should be implicitly strict. If modules themselves are implicitly strict, is this flag superfluous? myLoader.eval(someJS) is just like regular `eval`, and also loaders handle `eval` called from inside them. So no, the flag isn't superfluous. I fail to understand the benefit of forcing the mode of the loaded code. There is a risk to break the loaded code by forcing a mode it might not have been written for. Then you probably won't want to use this option when constructing loaders. Others, I'm sure, feel differently. I would most certainly use the option if I understood what use case it covers and found myself in the relevant situation. What's the use case? Out of curiosity, are there existing loaders libraries providing this feature too? What is the semantics of setting strict:false? David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Dynamic Modules Questions
This would imply that the result of the fetch hook is ignored if the
module has been installed in the module instance table before the hook
callbacks are executed. True?
This is the same for all the loader hooks, in fact.
Sounds good. Is there way, within a fetch hook, to conditionally fallback
to the loader's default behavior (or perhaps the base loader's behavior)?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Dynamic Modules Questions
(Referencing the module loaders proposal at
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders)
1) Loaders have a strict flag which indicates whether code evaluated in
the Loader's context should be implicitly strict. If modules themselves
are implicitly strict, is this flag superfluous?
2) What is the nature of the bindings created with the Module constructor?
In the following scenario, what is output?
var a = 123;
var M = new Module({ a: a });
a = 456;
console.log(M.a === a); // bound to var a or a new binding?
3) There doesn't appear to be a way to provide a dynamically created module
instance (created via the Module constructor) as the result of the fetch
hook. My thought is that such a feature might be useful for implementing
dynamically linked binary add-on modules in server environments.
Thanks!
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Dynamic Modules Questions
On Wed, Mar 6, 2013 at 9:46 AM, Kevin Smith khs4...@gmail.com wrote:
(Referencing the module loaders proposal at
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders)
1) Loaders have a strict flag which indicates whether code evaluated in
the Loader's context should be implicitly strict. If modules themselves are
implicitly strict, is this flag superfluous?
myLoader.eval(someJS) is just like regular `eval`, and also loaders
handle `eval` called from inside them. So no, the flag isn't
superfluous.
2) What is the nature of the bindings created with the Module constructor?
In the following scenario, what is output?
var a = 123;
var M = new Module({ a: a });
a = 456;
console.log(M.a === a); // bound to var a or a new binding?
This logs `false`.
3) There doesn't appear to be a way to provide a dynamically created module
instance (created via the Module constructor) as the result of the fetch
hook. My thought is that such a feature might be useful for implementing
dynamically linked binary add-on modules in server environments.
This is a good thought, and one we've considered. Note that you can
simply dynamically add the module using `System.set` during the fetch
hook. We may have more to say about a simpler API for this case in a
little while.
Sam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Dynamic Modules Questions
3) There doesn't appear to be a way to provide a dynamically created
module
instance (created via the Module constructor) as the result of the fetch
hook. My thought is that such a feature might be useful for implementing
dynamically linked binary add-on modules in server environments.
This is a good thought, and one we've considered. Note that you can
simply dynamically add the module using `System.set` during the fetch
hook.
This would imply that the result of the fetch hook is ignored if the module
has been installed in the module instance table before the hook callbacks
are executed. True?
Also, what is `System` exactly? The base loader or something else?
We may have more to say about a simpler API for this case in a
little while.
So mysterious! : )
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
