Discuss
  • Dynamic Modules Questions

Dynamic Modules Questions

# Kevin Smith (13 years ago)

(Referencing the module loaders proposal at 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.

# Sam Tobin-Hochstadt (13 years ago)

On Wed, Mar 6, 2013 at 9:46 AM, Kevin Smith <khs4473 at gmail.com> wrote:

(Referencing the module loaders proposal at 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.

  1. 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.

  1. 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.

# Kevin Smith (13 years ago)
  1. 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! : )

# David Bruant (13 years ago)

Le 06/03/2013 23:31, Sam Tobin-Hochstadt a écrit :

On Wed, Mar 6, 2013 at 9:46 AM, Kevin Smith <khs4473 at gmail.com> wrote:

(Referencing the module loaders proposal at 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.

# Sam Tobin-Hochstadt (13 years ago)

On Mar 6, 2013 10:04 PM, "Kevin Smith" <khs4473 at gmail.com> wrote:

  1. 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 Tobin-Hochstadt (13 years ago)

On Mar 7, 2013 4:53 AM, "David Bruant" <bruant.d at 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 <khs4473 at gmail.com> wrote:

(Referencing the module loaders proposal at 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.

# David Bruant (13 years ago)

Le 07/03/2013 13:19, Sam Tobin-Hochstadt a écrit :

On Mar 7, 2013 4:53 AM, "David Bruant" <bruant.d at gmail.com <mailto:bruant.d at 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 <khs4473 at gmail.com <mailto:khs4473 at gmail.com>> wrote:

(Referencing the module loaders proposal at 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?

# Kevin Smith (13 years ago)

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)?

# Aymeric Vitte (12 years ago)

Le 06/03/2013 23:31, Sam Tobin-Hochstadt a écrit :

  1. 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.

Does Module support the structured cloning ? (ie can you store M in indexedDB for example ?)

Example, could we store M :

var a='123'; var M=new Module({ a: function(data) {return window.something(a,data) } });

,

# Erik Arvidsson (12 years ago)

On Thu, Mar 21, 2013 at 12:22 PM, Aymeric Vitte <vitteaymeric at gmail.com>wrote:

Does Module support the structured cloning ? (ie can you store M in indexedDB for example ?)

I don't see how that would be possible since functions cannot be cloned. Functions may reference things in its lexical context.