Simple Modules: lazy dependency evaluation

Brendan Eich brendan at mozilla.com
Wed Jan 26 14:04:36 PST 2011


On Jan 26, 2011, at 1:54 PM, Kam Kasravi wrote:

> I assume you mean m.load("la1").

What is m?

Where did "la1" come from?

Confusion.


> So what is the behavior if you do new m.load("la1").Foo() if you know Foo is an exported object?

Sam addressed that directly ("nothing is statically known"), cited in full below.

Also, you can't violate JS's run to completion execution model by nesting an event loop and blocking on that load until the module, which could be on a far away server or even a too-slow-to-block-on disk filesystem, finishes loading.

CommonJS may do that on the server side, assuming fast enough file i/o. It's not necessarily a good idea even there (Ryan Dahl has talked about this). On the client, it's right out, which is why client-side CommonJS-like module systems require a preprocessor or else a callback.


> Is there a module API that allows one to introspect a modules content?

Are you reading the wiki?

/be

> 
> 
> 
> On Jan 26, 2011, at 1:46 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> 
>> On Wed, Jan 26, 2011 at 2:04 PM, James Burke <jrburke at gmail.com> wrote:
>>> CommonJS Modules 1.1 allows this kind of construct in module code:
>>> 
>>> var a;
>>> if (someCondition) {
>>>   a = require("a1");
>>> } else {
>>>   a = require("a2");
>>> }
>>> 
>>> and the module "a1" is not actually evaluated until execution reaches
>>> the a = require("a1") call.
>>> 
>>> 1) Could something like this work in Simple Modules? If so, what would
>>> be the syntax for it?
>> 
>> You can use module loaders to do exactly this (I believe, based on my
>> understanding of CommonJS).  It would look like:
>> 
>> var ml = ... the desired module loader ...
>> var a;
>> if (someCondition) {
>> a = ml.load("a1");
>> } else {
>> a = ml.load("a2");
>> }
>> 
>> This produces a module instance object, bound to |a|.  It doesn't,
>> however, allow you to import from |a|, since nothing is statically
>> known about what the exports of |a| are.
>> 
>>> 2) What are the design decisions behind only allowing "module" and
>>> "use" at the top level of a module?
>> 
>> Modules are a statically scoped construct, and the implementation and
>> the programmer can both statically tell where variables come from.
>> This prevents modules from being dynamically created, except in the
>> context of module loaders, as seen above.
>> -- 
>> sam th
>> samth at ccs.neu.edu
>> _______________________________________________
>> 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



More information about the es-discuss mailing list